Merge PR pour les tags V# and C#

#37

Le fond de l’article Terrains pour grimper : L’escalade en falaise et la couenne n’a pas évolué depuis sa création en 2008.
Il serait utile de mentionner les couennes avec relai intermédiaire facultatif, la présence de grandes voies dans des secteurs de couenne, dont la première longueur est utilisée comme couenne (et donc usée plus rapidement), les couennes rallongées en grande voie des années après leur équipement initial, etc.
D’ailleurs, dans l’article sur l’escalade en grande voie, il est indiqué qu’une grande voie est à partir de 3 longueurs.

Ce qui est important pour les définitions, est ce qu’on doit cocher dans le champ « type de voie » d’un itinéraire escalade, ou « type de site » dans un point de passage site d’escalade (couenne, grande voie, bloc, psycobloc). Mais actuellement il n’y a pas d’aide contextuelle pour ce champ.

#38

Ah pardon je savais pas.

Mais genre ici les voies avec relais intermédiaire peuvent faire juste 15 ou 20m, c’est pas des grandes voies du tout…

#39

Je ne vois pas où est le pb. On pourra evtl. utiliser C# et V# dans la même table.

#40

C’est pas si simple quand même, notamment dans les couennes dures (7, 8 , 9). Les relais inter, les combinaisons, etc ne sont pas rares. Un exemple : Seynes là où c’est dur sur colos. Il y a quasi systématiquement 2 étages. Tu fais le bas,le haut, tu enchaînes, tu mixes,…
C’est pas aussi mathématique que plus d’une longueur = gv

1 Like
#41

Exemple de topos de couenne du coin qui ont plusieurs longueurs :

image image

Chaque voie est indiquée en mode « 6 : première longueur 4c+, seconde longueur 5a/5b ». Et on est sur des voies de 20-30 m max. C’est pas de la grande voie (vu qu’une longueur peut faire genre… 5 mètres), c’est de la couenne avec des relais intermédiaires :wink:

Mais bref on diverge :slight_smile:

#43

Avec le C#, on pourra faire :
1 Eh prise, es-tu là ? 7a 25 m
2’L1 Le grand voyage 5c 15 m
2’L2 6b 12 m
3 Dré dans la mousse 5b 20 m

Ou simplement :
1 Eh prise, es-tu là ? 7a 25 m
2 Le grand voyage - L1 5c 15 m
2 Le grand voyage - L2 6b 12 m
3 Dré dans la mousse 5b 20 m

Dans les 2 cas, on perd la numérotation automatique pour tout le secteur, il faut ajouter le numéro à la main (C#2’L1 ou C#2).
Les seuls caractères de non alphanumériques supportés en suffixe du numéro de la longueur sont ’ et "

#44

Ou simplement, sur le fond, on accepte que l’on a pas les moyens de supporter une syntaxe qui supportera automatiquement toutes les situations du terrain (pour autant qu’elle existe), et on rajoute "markdown.extensions.tables" ici.

Ce qui permet de mettre absolument ce qu’on veut dans la première cellule, et nous évite toute bidouille au rendu malheureux. Et pour le meme prix, on peut faire des tableaux, fonctions qui peut etre utile à de nombreux endroits.

# Nom Cotation Hauteur
1 Eh prise, es-tu là ? 7a 25 m
2 - L1 Le grand voyage 5c 15 m
2 - L2 Le grand voyage 6b 12 m
3 Dré dans la mousse 5b 20 m

A noter également que si pour une grande voie, la numérotation des longueurs est indispensable, c’est moins évident pour les couennes. Le tableau suivant peut tout aussi se défendre :

Nom Cotation Hauteur
Eh prise, es-tu là ? 7a 25 m
Le grand voyage (L1) 5c 15 m
Le grand voyage (L2) 6b 12 m
Dré dans la mousse 5b 20 m

Ce tableau sans numérotation, si jamais il s’avère etre celui voulu, est impossible aujourdhui sans pondre une infame tartine d’HTML.

1 Like
#45

Oui ça serait cool d’avoir les tableaux, mais ça ne répond pas au besoin d’ici, comme débattu plus haut… On tourne en rond.

#46

Le besoin, c’est d’avoir des tableaux pour faire des couennes. Donc, je pense que ca y répond.

La numérotation automatique, ce n’est pas un besoin, c’est une potentielle facilité syntaxique pour faire quelque chose qui se fait sans trop de problème à la main.

Et mon objection sur le fond, c’est que la solution proposée, à savoir C# et V#, pour avoir cette numérotation rajoute de la complexité au code et sera non intuitive dans d’autre langues. Je rajoute également à la lecture des dernier messages que la diversité des situations va forcer à utiliser une syntaxe alambiquée pour un résultat peu convaincant dans des cas pas si rares.

Ca renforce donc mon opinion que c’est une mauvaise idée, et qu’il faut plutot preferer partir sur l’extension officielle qui permettra toute la souplesse nécessaire, pour un coup de maintenance proche du nul.

#47

OK je laisse tomber, je vais chercher un autre site pour faire mes topos du coup :slight_smile:

#48

Je ne suis pas sur de bien comprendre la raison de ta réaction. Pour toi, la numérotation automatique était si indispensable pour pouvoir faire ce que tu voulais ?

#49

Oui, très utile.

#50

Je tente une dernière fois de réveiller cette discussion pour obtenir l’approbation de cette PR.

En effet, comme exposé auparavant, il est nécessaire de ne pas utiliser des tableaux génériques ici car nous avons besoin de conserver le sens sémantique des voies d’escalade, qui puissent donc être identifiées ensuite pour générer automatiquement des topos PDF et papier pour les falaises de ma région.

Les tableaux génériques Markdown ne permettent pas de faire ça. Je suis aussi pour activer les tableaux markdown bien sûr, mais leur usage est différent, car il n’indique aucune sémantique permettant de réutiliser les données entrées dans camptocamp.

#51

Si les tables génériques sont utilisées, la modération topoguide choisira une convention pour désigner les topos de couennes dans un souci d’homogénéité, et veillera à ce que cette convention soit respectée (cf le threads sur les vérifications automatiques, il y a bien une chose ou la modération est efficace, c’est dans l’homogénéisation du topoguide).

En conséquence, cette convention sera tout aussi fiable qu’une sémantique faisant partie de la syntaxe.

En clair, tous les topos d’escalade utiliseront ce code (ou une autre, le point est qu’il sera utilisé et commun à tous les topos) :

| V1 | Biographie
| V2 | Burden of dream

La sortie est une table, et le code est aussi identifiable que V# | Biographie. En pratique, si tu as un point de passage de type couenne, et que tu trouves un ligne commancant par « | V<un nombre> », tu peux etre sur à 100% que c’est une liste de voie.

Ou bien je rate quelque chose ?

#52

Au passage, tu peux me montrer l’outil que tu comptes utiliser pour générer automatiquement des topos PDF, je pourrais peut-etre me rendre mieux compte ou ca coince ?

#53

Ben oui.
On veut définir une balise V# ou C# pour ne pas utiliser L#, qui donne un affichage avec L1, L2, …, alors qu’on veut 1, 2, … (tout en conservant V# dans le code, donc la moulinette de @bohwaz ferait la différence entre tableau de couennes et tableau markdown ou html donnant le même affichage).
Et comme méthode alternative, tu proposes de mettre V1, V2, …, y compris à l’affichage.

#54

tu proposes de mettre V1, V2, …, y compris à l’affichage.

Ben non… J’ai mis une convention en précisant, je cite : « ou une autre, le point est qu’il sera utilisé et commun à tous les topos ».

Ben du coup si tu veux 1, 2 … à l’affichage, alors le code sera :

| 1 | Biographie
| 2 | Burden of dream

Tu mettras ben ce que tu veux.

#55

Comment tu fait dans ce cas pour différencier un tableau de voies sportives d’un tableau qui liste d’autres informations par ordre numérique ?

Pour moi ça répond pas vraiment au besoin…

#56

Combien y’a t-il d’exemple de ce type dans les points de passages ? Je ne vais pas affirmer qu’il n’y en a aucun, quelqu’un va trouver un contre exemple :slight_smile:

Un point clef pour comprendre mon point de vue, c’est que ce qui doit diriger les décisions sur le parseur, c’est en priorité l’ « utilisabilité » pour le contributeur de camptocamp, versus le cout de maintenance. La réutilisation des données derrière est un objectif secondaire qui ne peut etre mis sur le meme plan que les objectifs prioritaires. En clair, il ne serait pas responsable de rajouter de la complexité dans le parseur, si la principale raison est de simplifier la vie d’une tierce partie.

Pour avancer, admettons l’improbable : il y aurait en effet d’autre tableaux d’informations par ordre numérique dans les points de passage, et trop nombreux pour que ton outil ait une liste d’exceptions. Alors on peut trouver d’autres filtres, par exemple la présence d’une cotation dans une cellule. En code, cela peut se faire en une ligne avec une expression régulière.

=> La complexité en plus dans ton outil sera bien inférieure à celle que tu aurais introduit dans le parseur. Et c2c n’aura pas à la maintenir. Pour moi il n’y a pas photo.

Encore une fois, je peux te filer un coup de main si ca peut etre utile, n’hésite pas.

1 Like
#57

Comme indiqué plus haut dans ce fil, mon patch n’ajoute aucune complexité dans le parseur, ça ne fait que réutiliser une logique qui existe déjà…

1 Like