Checklist devrait-il prendre en charge la syntaxe des cases à cocher GFM ?

J’ai donc remarqué certaines listes de tâches existantes sur mon instance qui affichaient l’ancienne syntaxe avec des astérisques. J’ai décidé d’exécuter la tâche rake ci-dessus, mais elles ne sont pas mises à jour.

Si ma mémoire est bonne, la plupart des autres listes de tâches ont été migrées silencieusement vers la nouvelle syntaxe lors de mes mises à jour de Discourse au cours des dernières semaines. Mais il semble qu’il y en ait certaines étranges que la tâche rake laisse de côté. Quelqu’un aurait-il une idée de la raison pour laquelle cela pourrait arriver ?

Je suis prêt à fournir plus d’informations si cela aide au débogage.

Mise à jour : il semble que l’un de ces messages ait la syntaxe [\*] (celle générée automatiquement lors de la cocher la case depuis l’interface utilisateur). Peut-être est-ce le cas manqué par la tâche rake ?

4 « J'aime »

@k4rtik, à ce que je me souvienne, la tâche rake ne modifie les cases à cocher que lorsqu’elles se trouvent au début d’une ligne.

Les pages que je vois ont toutes des cases à cocher au début de la ligne. La question est de savoir si la tâche modifie à la fois [*] et [\*] ou seulement la première syntaxe ?

Cette ligne devrait vérifier si la case à cocher se trouve dans les trois premiers caractères de la ligne. Je viens de vérifier l’expression régulière et elle semble correspondre correctement.

3 « J'aime »

Les listes de tâches ne commencent-elles pas toujours par un marqueur de puce (* ou -) en premier [1, 2], de sorte que l’expression régulière devrait correspondre à :
- [\*]
ce qui fait que cela est ignoré car il n’est plus dans les trois premiers caractères.

J’ai ensuite découvert d’autres cas où j’ai des cases à cocher imbriquées. Donc, supposer qu’elles sont au début de la ligne ignorera également beaucoup de cas d’utilisation valides.

PS : J’ai réalisé que l’OP ici n’utilise pas la syntaxe de liste de tâches GFM (mais seulement depuis le 4 août avec le changement de wiki par @sam), mais je l’utilise depuis toujours. La spécification CommonMark à laquelle Discourse semble se référer pour la documentation Markdown ne semble pas encore prendre en charge les listes de tâches. Discourse invente-t-il sa propre variante de la syntaxe de liste de tâches ? Je préférerais m’en tenir à la syntaxe GFM largement populaire plutôt que de la diversifier davantage.

Pourriez-vous fournir un lien vers la spécification de la syntaxe de la liste de contrôle GFM ?

Je l’ai lié ci-dessus, mais le voici à nouveau :

Ça me semble correct ici, en copiant les deux exemples du lien ci-dessus :

- [ ] foo
- [x] bar

donne

  • foo
  • bar

et

- [x] foo
  - [ ] bar
  - [x] baz
- [ ] bim

donne

  • foo
    • bar
    • baz
  • bim

Donc je ne vois pas vraiment quel est le problème ? Pourriez-vous être plus précis ?

Désolé, cela semble confus car les choses ont changé assez récemment. Je fais référence à la capture d’écran affichée sur la page du plugin, qui ne montre pas la syntaxe de la liste à puces (et que la tâche rake migrate ne semble pas prendre en charge) :

Voici la capture d’écran du diff qui a introduit le changement :

C’est difficile à voir, mais le côté gauche présente des cases à cocher à puces, tandis que le côté droit actuel supprime les puces, suggérant une syntaxe de case à cocher par défaut différente pour les nouveaux utilisateurs.


Ajouté ultérieurement :

Autrement dit, toutes ces variantes sont désormais prises en charge par le plugin checklist :

[] first
-[] second
- [] third

rendu sous la forme :

first
- second

  • third

alors que la spécification tasklist de GFM n’autorise que la troisième variante (car une tasklist est une liste) :

Un élément de liste de tâches est un élément de liste dont le premier bloc est un paragraphe commençant par un marqueur d’élément de liste de tâches suivi d’au moins un caractère d’espace avant tout autre contenu.

Un marqueur d’élément de liste de tâches consiste en un nombre optionnel d’espaces, une crochets ouvrant ( [ ), soit un caractère d’espace soit la lettre x en minuscule ou majuscule, puis un crochet fermant ( ] ).

Si l’on souhaite se conformer à la spécification de l’extension tasklist de GFM, alors les deux premières variantes ne devraient pas être autorisées ni mises en avant dans la documentation du plugin.

1 « J'aime »

Prendre en charge le cas GFM ne signifie pas exclure les autres cas. Si vous extrapoliez cette logique, cela nécessiterait de nombreux changements négatifs dans la façon dont Discourse gère toutes sortes de formats Markdown.

De nombreuses applications génèrent des cases à cocher Markdown ; il est très pratique de pouvoir coller des listes dans les publications Discourse. Quel intérêt y a-t-il à rompre la compatibilité ?

1 « J'aime »

L’un des principaux problèmes du Markdown est l’absence d’une norme commune (CommonMark s’efforce de remédier à cela), ce qui entraîne une variété d’implémentations incompatibles. Lorsqu’il existe déjà une extension de liste de tâches extrêmement populaire sous la forme de GFM, pourquoi faut-il en inventer une autre ? J’avais l’impression que les développeurs de Discourse étaient engagés en faveur de CommonMark et de la standardisation du Markdown.

Mon problème ne porte pas sur le support de syntaxes alternatives ; je crois à la loi de Postel (même si je pense que la question susmentionnée aurait dû être prise en compte lors des dernières modifications de syntaxe, c’est-à-dire le passage de [*] à [x]). Mon souci concerne la promotion d’une syntaxe incompatible avec GFM dans la documentation du plugin, ainsi que l’absence de prise en charge d’une migration facile de la syntaxe de liste de tâches de type GFM vers le nouveau format. Cela a cassé de nombreuses pages de mon instance Discourse, comme expliqué dans mon message initial.

3 « J'aime »

Nous venons effectivement de modifier la syntaxe pour la simplifier. Vous pouvez utiliser [] n’importe où dans un message pour créer une case à cocher. Je ne prévois pas de le modifier à nouveau dans un avenir proche. Vous êtes bien sûr libre de créer un fork du plugin pour implémenter ce que vous souhaitez.

2 « J'aime »