Hello, est-ce que quelqu’un pourrait merger (ou me faire des retours) sur ma PR :
Merci 
Merge PR pour les tags V# and C#
1 Like
Je ne vois pas bien l’intérêt d’avoir 2 préfixes donnant le même résultat. Un préfixe est arbitraire de toute façon, même si on essaye de le rapprocher d’une abréviation.
Mais ce n’est pas bien gênant, à part quand on fait des copier-coller entre traductions pour des mises à jours d’une traduction, ça aboutira à des mélanges de V# et C# qui paraitront bizarres, alors que ça fonctionne bien.
Sinon il y a aussi moyen d’avoir cela pour toutes les lettres (A# - Z#), ce qui donnerait bien de la flexibilite - notamment pour les langues etrangeres. Mais il faut bien sur aussi considerer qu’avec un plus grand rayon d’activite, il y a plus de possibites de faire des erreurs.
Je rejoins Bubu, il ne faudrait qu’un alias pour un tableau sans rien.
On peut par contre envisager d’étendre le L# avec des S# (allemand) et P# (anglais) …
+1
Ce qui serait logique, d’un point de vue syntaxe, c’est que n’importe quelle majuscule sot autorisée (L#, C#, Z#, W#), et soit traité de la meme facon par le parseur (-> L1, C1, Z1, W1… ), charge à la communauté de décider le sens qu’elle veut donner à chaque lettre, ce sens ne concerne pas le parseur.
Et effectivement avoir un alias pour un tableau sans rien. # n’est pas possible, c’est le titre. Un alias possible serait le pipe en début de ligne, il est deja utilisé pour séparer les cellules, et reste dans la logique du markdown d’avoir une syntaxe simple, et naturellement utilisée pour simuler le rendu souhaité avec des caractère simples :
| cell1 | cell2 | cell3
| cell1 | cell2 | cell3
| cell1 | cell2 | cell3
Je preconiserais meme de rechercher si il n’existe pas une extension qui fait ce boulot, histoire de ne pas recoder la roue.
Je peux changer le préfixe, j’ai juste repris le principe existant de L/R (ligne/route). N’hésitez pas à me dire ce que vous préférez.
C’est pas le sujet ici, ici c’est pour faire des topos d’escalade, donc avoir des références entre voies est intéressant.
Si quelqu’un veut proposer une PR pour des tableaux pas de souci, mais c’est pas le sujet de mon patch
Ah non, L# c’est pour la description des longueurs, R# est pour la description des rappels. Exemple : Camptocamp.org
On peut utiliser R# dans le texte des longueurs pour afficher R4 avec numérotation automatique.
Sur la V6, il n’y a aucune différence de fonctionnalité entre L# et R#.
Mais l’idée (qui existait sur la V5) était que R# en début de ligne (ou dans le texte d’une ligne R#) était transformé en Rp4, pour différencier les relais des longueurs et les relais des rappels.
Il y aurait aussi la possibilité de faire varier l’affichage en fonction de la langue.
Mais bon, a priori comme on n’aura pas besoin de balise [A-Z]# pour une autre fonctionnalité, on pourrait autoriser n’importe quelle lettre, qui serait affichée tel quel (par contre plus d’évolution possible du style R# qui se transforme en Rp4).
J’ai aucune idée des conséquences mais vu de l’extérieur ouvrir la solution à toutes les lettres, ce serait bien.
1 Like
OK mais ici l’idée c’est de ne pas avoir de lettre qui s’affiche justement. Donc je vois pas le rapport avec toutes les lettres.
Ah oui c’est vrai. Ta proposition est d’avoir une fonctionnalité différente pour les V# et C#, qui affiche le numéro (automatique ou non), mais pas le ‹ L ›.
Du coup, pas d’objection à part que j’aurais mis un seul préfixe C#, mais bon en avoir 2 ne gêne pas (C = crag, couenne - V = voie, via).
Ce qu’on veut dire, c’est que si le besoin « pas de lettre » existe, réserver une lettre de syntaxe pour cela n’est pas forcément idéal :
- De une cela de demande de se souvenir de quelle lettre il s’agit, ce qui est forcément très arbitraire par rapport aux autre lettres, et n’aura pas de sens dans d’autres langues
- De deux, cela interdira l’usage de cette lettre dans une langue donnée. Imaginons que en klyngons, le terme pour « Longueur » est de manière évidente « Vlyx », et il n’y a rien d’autre. Les klyngonais auront très naturellement envie d’utiliser
V#. Cela ne sera pas possible, carV#est réservé pour les tableaux sans préfixe de longueurs.
Donc en clair :
- il faudrait trouver une autre syntaxe, qui ne serait pas basée sur un quelconque
L#,R#,C#,X#… pour les tableaux sans numérotation (l’objet de ta PR) - Et au passage, on divergeait sur l’interet d’ouvrir d’autoriser n’importe quel
L#,R#,C#,X#… pour les tableaux avec numérotation (ce qui n’est pas l’objet de ta PR, et donc à faire pour plus tard)
Sa PR ne concerne pas les tableaux sans numérotation, mais sans préfixe avant le numéro :
C# | Le cri de la chouette | 6b | 25 m | 10 pts | Pas de bloc à 10 m, le reste en 5c/6a.
C# | Dré dans la mousse | 7a | 30 m | 13 pts | Brossage préventif conseillé.
donne :
| 1 | Le cri de la chouette | 6b | 25 m | 10 pts | Pas de bloc à 10 m, le reste en 5c/6a. | |
| 2 | Dré dans la mousse | 7a | 30 m | 13 pts | Brossage préventif conseillé. |
On pourrait avoir une syntaxe avec juste un nombre, avec le même principe que le L# de pouvoir ajouter un suffixe, avec la conséquence de la perte de la numérotation automatique.
1 | Le cri de la chouette | 6b | 25 m | 10 pts | Pas de bloc à 10 m, le reste en 5c/6a.
1 | Dré dans la mousse | 7a | 30 m | 13 pts | Brossage préventif conseillé.
Et :
3gauche | Le cri de la chouette | 6b | 25 m | 10 pts | Commun avec _Dré dans la mousse_ sur 4 points, puis à gauche. Pas de bloc à 10 m, le reste en 5c/6a.
3droite | Dré dans la mousse | 7a | 30 m | 13 pts | Commun avec _Le cri de la chouette_ sur 4 points, puis à droite. Brossage préventif conseillé.Oui moi j’avais pensé à juste le dièse #1 | Voie | Cotation mais ça entre en conflit avec les listes numérotées et titres. D’où le C/V, le risque de confusion est faible.
Dans ta suggestion de supprimer complètement le # ça enlève de l’intérêt car on ne peut plus faire des réfs genre Relais commun avec V#52.
De plus les tableaux classiques en Markdown nécessitent d’avoir un entête :
| Colonne 1 | Colonne 2 |
| --- | --- |
| Bla | Blu |
Il me semble que c’est justement pour éviter les confusions. Du coup ça ne colle pas non plus avec le besoin ici.
1 Like
Quel serait le rendu dans ce cas ?
Relais commun avec 52.
ou
Relais commun avec 52.
Dans le premier cas, il n’y a aucun intérêt à utiliser une balise. Ca aurait un sens si on pouvait utiliser la numérotation automatique avec un index relatif (du style V#+1, V#-2), mais ça a été abandonné dans la V6 pour simplifier le parser.
Dans le 2nd cas, il y a une mise en forme spécifique (avec une classe spécifique permettant de faire évoluer la mise en forme juste en modifiant le CSS). La balise est utile.
L’idéal serait qu’une balise V#52 dans le texte soit remplacée par le nom de la voie :
Relais commun avec Le cri de la chouette (52).
Mais ça demande de parser 2 fois pour générer la liste des noms de voie lors de la 1re passe.
Second cas.
L’objectif est de pouvoir reprendre ça dans un topo papier/téléphone au final, et donc d’appliquer des CSS pour montrer que tu référence une autre voie sur papier, et que sur le topo téléphone quand tu clique sur le numéro de voie ça t’emmène à son index et la mette en évidence sur le topo photo. D’où l’intérêt d’avoir une syntaxe spécifique qui indique qu’on fait référence à une voie et que c’est pas juste un nombre normal.
OK, du coup pas besoin de minimiser la syntaxe, vu qu’on ne veut pas simplement une mise en forme, mais aussi ajouter des fonctionnalités d’interaction.
Mon patch ajoute à peine 10 lignes de code… Il y a un test unitaire… Il n’y a rien de plus à maintenir ici… Et plutôt que de créer une nouvelle extension j’ai repris la logique existante… Je vois pas concrètement ce que tu propose de mieux ?
Ton patch adresse deux besoins :
- Faire des tableaux avec juste des numéros dans la première colonne
- avoir des
spanavec la classepitchsur ces numéro
Pour cela, elle réserve arbitrairement deux lettres qui n’ont de sens que dans deux langues, rendant la syntaxe globale moins générique.
Et elle rajoute un peu de complexité (faible je te l’accorde très volontiers, et tu as d’ailleurs fait le taf très bien) à une extension assez complexe. Mais la précédente complexité dont je parle qui a conduit à la catastrophe a été le fruit d’une longue succession d’ajouts non maitrisés, pour la plupart qui sont très simple si tu les prends individuellement.
Chaque complexité sur cette partie du code doit mesurée avec attention.
Utiliser une extension existante que nous n’avons pas à maintenir pour faire des tableaux simples.
Si un besoin existe sur un element inline, faire une extension avec un parser inline indépendant qui ne rajoutera aucune complexité à l’extension ltag.
Mais avec ça, on perd la numérotation automatique, fonctionnalité qui est utilisée aujourd’hui pour les couennes !
L’idée est que pour migrer les tableaux de couennes existants, on se contente de remplacer L# par C#, et zou. Ca peut se faire à la chaine ou par un robot. Alors que remplacer les L# par une numérotation manuelle… Sans parler de la maintenance quand une ligne est ajoutée après la 3è, alors qu’il y en a 50…