Cuisine avec C++

(Premier post, alors soyez indulgent…)

J’ai récemment configuré mon propre forum Discourse : https://crucible.hubbe.net/. Pour l’essentiel, j’en suis très satisfait. La communauté est dédiée à une carte de type Arduino, utilisée principalement par les créateurs de décors. En conséquence, nous utilisons beaucoup de code C++ basé sur des modèles. En particulier, nous utilisons ce qu’on appelle un « style », qui configure l’apparence des lumières. Les styles peuvent être complexes, alors j’ai créé un éditeur/aperçu en ligne, puis j’ai utilisé le composant de thème discourse-linkify pour que les styles soient automatiquement liés à l’éditeur. J’ai dû apporter quelques modifications mineures au composant de thème discourse-linkify pour que les caractères d’URL soient correctement cités, etc., ce qui était assez simple. Je peux créer une demande de tirage (PR) pour ces modifications si cela intéresse quelqu’un.

Le résultat peut être consulté ici : https://crucible.hubbe.net/t/styleptr-links/286

Cependant, il y a un problème…
Certains des codes basés sur des modèles ressemblent un peu à du HTML à cause de tous les caractères < et >, et à un moment donné, Discourse supprime certains de ces « balises ». En gros, il semble que tout mot inconnu encadré par < > soit supprimé. La ligne suivante de ce post sera mais sans les espaces :

< - le foo est ici

Au début, je pensais que c’était le composant linkify qui faisait quelque chose de mal, mais après quelques recherches, il semble que le contenu manquant ait déjà disparu avant que linkify ne s’exécute. Donc, je suppose que les balises supplémentaires se sont évaporées quelque part dans le processus de cuisson ?

J’ai remarqué que dans les blocs de code (triple backtick et similaires), les balises survivent, mais pour mes besoins, il vaudrait mieux qu’elles survivent toujours.

Pendant un moment, j’ai pensé qu’il suffirait de modifier discourse/lib/utilities.cs : CODE_BLOCKS_REGEXP pour que cela fonctionne, mais inCodeBlock n’est pas utilisé depuis de nombreux endroits, alors peut-être que c’est une mauvaise piste ? De plus, je n’ai pas encore trouvé comment modifier réellement CODE_BLOCKS_REGEXP à partir d’un plugin ou d’un composant de thème.

Quel code est réellement responsable de la suppression de ces balises ?
Quelle est la meilleure (la plus prise en charge) façon de la désactiver ?

Je dois également souligner que, comme les utilisateurs collent parfois de gros blocs de code, il peut être très difficile de remarquer que certaines parties au milieu ont disparu. Au minimum, il serait préférable que les balises inconnues soient remplacées par des signes d’avertissement clignotants ou quelque chose qui informe l’utilisateur qu’un événement inattendu s’est produit.

Question : pourquoi ne pas essayer d’utiliser des blocs de code Markdown ?

Entourez simplement votre code avec des triples accents graves : le caractère `.

Comme ceci

here 
<foo>
is <some> </fooer> </foo>

Et voici le code source réel de mon message : https://meta.discourse.org/raw/187974/3


Vous devrez éduquer vos utilisateurs, mais c’est votre travail en tant que modérateur, et cela aidera tous les utilisateurs qui devront gérer Markdown plus tard.

Vous pouvez le faire en créant un nouveau sujet épinglé global, du genre « Comment intégrer du code sur ce site » ou « Comment taper sur ce site ».

Vous pouvez également les diriger vers ce lien : Référence Markdown (commonmark.org)

D’accord, je voulais juste partager ce lien au cas où d’autres personnes rencontreraient le même problème.

Il semble que l’ajout de backticks et d’un lien en suivant le même modèle que celui utilisé par le plugin piratize résoudrait le problème.

Parce que j’ai mieux à faire que de chasser des chats ?
S’il existe un moyen simple et un moyen correct de faire les choses, les gens choisiront toujours le moyen simple. Je suppose que si je pouvais réellement empêcher les gens de placer des modèles StylePtr<> en dehors du texte préformaté, alors ils seraient contraints de faire les choses correctement, mais comment puis-je faire cela ? (En outre, cela semble être une solution très brutale, car elle pourrait aussi empêcher des façons parfaitement valables de parler des modèles StylePtr<>.)

Ma solution actuelle pour lier les modèles StylePtr<> en utilisant linkify ne fonctionne pas non plus sur le texte préformaté car le DOM est très différent, mais c’est un problème mineur que je peux probablement résoudre avec un peu de codage.

Peut-être. Je pense que ce que je ferais, c’est utiliser ce motif pour ajouter automatiquement les backticks s’ils ne sont pas présents, puis utiliser un callback post-cuisson pour le lien. Sauf erreur de ma part, il n’y a pas d’autre moyen d’ajouter un lien au milieu d’un texte préformaté.

Encourager les utilisateurs à utiliser des accents graves pour le code en ligne et trois accents graves pour les blocs de code est la meilleure solution. Peut-être créer un sujet épinglé à ce sujet sur votre forum ?

En plus de cela, vous pouvez essayer Unformatted Code Detector.

Le composant de thème pour le détecteur de code non formaté semble prometteur.
Ensuite, je dois simplement créer un composant de thème qui gère les liens à l’intérieur du code préformaté, ce que je comptais faire de toute façon. Je vais absolument essayer cela.

Il s’avère que tout ce que j’avais à faire était d’activer le support des expressions régulières multilignes dans le module linkify pour qu’il fonctionne plus comme je le souhaitais. Je pense donc que tout est en ordre, à condition que les gens prêtent vraiment attention au détecteur de code non formaté.