Markup : code block

#1

Le markup pour les code blocks ne considère pas le contenu comme du texte verbatim mais le formate en HTML.

cf. Camptocamp.org

Il s’agit bien de markdown ???

#2

L’extension utilisé est celle là (il n’y pas markdown universelle) : https://pythonhosted.org/Markdown/

#3

Mouarf !
A voir s’il y a une option pour gérer correctement les caractère ", &, < > , etc.
Ou si c’est un conflit avec autre chose.
Sinon, ça signifie qu’il va falloir recoder le parser markdown (ce que j’avais fait sur la V5 pour les sous-titres et les listes vu que l’original est plein de défauts rédhibitoires).

Sinon, il y a la balise [ code ], mais elle ne conserve pas l’indentation…
Quelle merde, ya rien de correct par défaut, faut tout hacker pour avoir le minimum intéressant…

#4

Je pense que c’est lié à la combinaison du parser markdown et du parser bbcode…

#5

Ben peut être, mais ça se gère. C’était le cas sur la V5.
Un parser ne peut pas être simplement constitué d’une succession de fonctions appliqués à du texte.
Il y a certaines balises ou fonctions qui nécessitent d’avoir une vue globale de ce qui se passe. Par exemple pour la balise [code], qui doit inhiber tout décodage, il faut la détecter tout au début, isoler le texte à ne pas décoder, décoder le texte restant, formater le texte non décodé (coloration syntaxique, etc), puis remettre ce texte formaté dans le reste du texte. Ca signifie qu’il faut une action au début, puis une autre à la fin.
Idem pour la conversion des "&<> en code html : il faut le faire à un moment bien précis, après le décodage du html s’il y en a (comme sur le forum), mais avant le décodage du reste, pour éviter que le code html ajouté par le décodage soit converti à son tour.
Donc ce n’est pas une question de « c’est à cause du bbcode, donc on supprime le bbcode » : tu auras le même problème avec du markdown s’il est mal codé, ou en ajoutant n’importe où le décodage des balises img spécifiques à c2c, ou n’importe quel pluggin pour la vidéo ou autre.

#6

OK. On a donc besoin que quelqu’un se penche sur cette partie et l’améliore. Des volontaires ?

#7

Normalement je suis volontaire, vu qu’il faut corriger des trucs dans le markdown (ancre des sous-titres, sous-listes à puces, certaines options, etc). Mais faut déjà que je finisse les L#…

#8

J’ai fait une page d’aide/test pour le markup

https://www.camptocamp.org/articles/840640/fr/page-d-aide-du-language-de-markup

1 Like
#9

J’ai testé avec Markdown==2.6.5 et je n’ai pas ces problèmes. Cela doit venir du code de v6_ui ???

#10

Ca vient surement de là :

#11

Est-il envisageable de parser tous les documents de la base, et remplacer les balises bbcode par du markdown ? C’est faisable ou infaisable ? On ne va pas maintenir les 2 éternellement, ça va devenir ingérable.

#12

C’est envisageable mais c’est du travail et ca aurait été plus facile de le faire au moment de la migration v5>v6 (mais plein d’autres choses à faire). A moins de modifier aussi les anciennes versions des documents, le formatage bbcode des anciennes versions ne sera plus affiché correctement quand on supprimera le parser bbcode.

#13

Ca concerne les liens, le gras, l’italique et les blocs de code.
Toutes les autres mise en formes sont disponibles uniquement en bbcode (souligné, barré, exposant, …) ou uniquement en markdown (sous-titres, listes à puces).

On peut remplacer les balises qui sont dans les 2 langages pour n’en conserver qu’un.
Mais pour ne pas déstabiliser les contributeurs, il faudrait remettre les boutons de mise en forme.
Malgré tout, s’il n’y a pas les boutons de gras, italique et souligné, ce n’est pas plus mal. Ca évite que les sous-titres et les descriptions de longueurs soient mis en forme avec ces balises, demandant aux modos d’enlever ces balises avant de mettre les bonnes. Souvent ça triple le temps pour améliorer la mise en forme d’un sous-titre par exemple par rapport à juste mettre la bonne balise sur du texte sans balise.
En pratique, le gras, italique et souligné est quasi inutile dans les docs c2c. En tout cas on l’utilise 10 fois moins que les sous-titres, liens, L#, listes à puces.
Quand on mettra des boutons, il faudrait un seul bouton pour la mise en forme des caractères, qui demande un clic pour afficher le détails des boutons, afin déviter que les boutons gras, etc soient directement accessibles. Les boutons de sous-titres seraient par contre directement accessible.

#14

J’ai compris ce qui se passe en regardant dans le code https://github.com/c2corg/v6_ui/blob/master/c2corg_ui/format/init.py un document est transformé en HTML en appelant le parser de bbcode http://bbcode.readthedocs.io puis celui de Mardown https://github.com/waylan/Python-Markdown. Malheureusement le parser de bbcode mène sa vie sans se soucier de Markdown et le parser de Markdown reçoit un mélange de HTML et de Markdown, ce qui casse une partie de la syntaxe Markdown.

Je penses que cela ne peut pas fonctionner, il faut soit implémenter la dizaine de markups de bbcode dans Markdown soit convertir les documents utilisant des bbcodes en Markdown. Avec un flag dans la base de données on pourrait le faire en lazy dans l’api.

Dans tous les cas, je crois que c2c à intérêt à avoir un markup opérationnel et relativement standard.

Les tags supportés par bbcode sont http://bbcode.readthedocs.io/en/latest/tags.html

#15

On est bien d’accord avec ça !
On se traîne un historique assez pénible. Et faire la moulinette pour corriger ça n’est pas complètement triviale et probablement un peu chronophage. Tu veux pas aider ? :stuck_out_tongue:

#16

Je peux donner un coups de main si j’ai un go.

#17

Qu’est-ce que tu entends par un go ?
Effectivement, avant de se lancer dessus il faudrait qu’on se mette d’accord sur ce qu’on peut envisager, et comment le faire. Par contre, si tu es motivé pour contribuer, personne ne te dira non :slight_smile:
Parmi les points à régler :

  • souhaite-t-on essayer de garder les deux syntaxes ?
  • est-ce qu’on préfère basculer sur markdown et ajouter aussi nos extensions du type L# (@Bubu toi qui travaille dessus tu fais ça à quel niveau actuellement) ?
  • est-ce qu’on essaye juste de corriger certains points ?
  • si on abandonne certaines syntaxes, quelle migration va-t-on appliquer et comment ?
  • en parallèle, quid des boutons d’aide à la syntaxe qui sont absents actuellement ?
  • …

Etc. Comme je disais c’est un gros sujet. Par contre si on arrive à avancer dessus, ça va être super.

#18

Un go des devs/board

J’ai regardé le code bbcode bbcode/bbcode.py at master · dcwatson/bbcode · GitHub c’est simple, il suffit de récupérer le tokenizer et de coder un convertisseur Markdown. Cela peut se faire en quelques heures. En espérant qu’il n’y a pas des clashs au niveau de la syntaxe.

Au sujet de l’aide à la syntaxe, je penses qu’actuellement cela peut freiner les moins geeks. Il faudrait une sorte de ckeditor. J’ai trouvé cet éditeur javascript pour Markdown https://simplemde.com GitHub - nextstepwebs/simplemde-markdown-editor

#19

Ben si tu trouves une syntaxe markdown pour souligner du texte, le barrer, le mettre en exposant ou en indice, pas de problème (ce sont des mises en forme actuellement supportées en bbcode dans le topoguide, mais pas en markdown).
Sinon, il faudra conserver une partie des balises bbcode.

Dans une extension markdown.

#20

Si on reprend la liste des bbcodes:

  • b oui
  • i oui
  • u Non
  • s text
  • hr oui
  • sub A1
  • sup A1
  • list oui
  • quote oui
  • code oui
  • center Non
  • color Non bien que red marche ici
  • url oui

Il existe text pour le barré et HTML pour sub/sup.
Il manque donc 3 bbcodes: souligné, center et color. On peut inventer ~-text-~ car bold existe dejà.