Salut à tous ! Je voudrais vous présenter le draft actuel du langage de forum de la v5 - nommé Lightscript, un gentil dérivé de Markdown conçu pour Planète Casio. J'ai noté RFC (Request For Comments) dans le titre, c'est une manière fun de dire que vous êtes invités à donner votre avis !

2018-02-06 : La spécification est freezée jusqu'à nouvel ordre ; j'implémente. Vous pouvez quand même faire des remarques ou proposer des extensions, elles sont bienvenues !

Ce langage servira à écrire tout ce qui existera sur la v5 ou presque : les messages sur le forum, les descriptions et commentaires de programmes, les tutoriels, les messages privés, etc etc. Les seules exceptions notables que je puisse déjà évoquer sont les tutoriels, que l'on pourra aussi écrire (au choix) en LaTeX, et l'IRC qui fait bien ce qui lui plaît.

Je tiens à préciser que je suis en train d'implémenter le programme de conversion (vers HTML), mais je débute encore. Rien n'est définitif, tout est discutable.

La description du langage est ci-dessous : vous pouvez réagir sur l'ensemble ou pointer des conflits de syntaxe, des oublis, des fonctionnalités manquantes qui vous sembleraient intéressantes. Il y a des choses que j'ai éliminées volontairement ; je les ai citées tout à la fin avec un argumentaire. N'hésitez pas à en discuter. Je compte sur vous !

Le modèle « théorique »

Sans rentrer dans les détails compliqués, un message en Lightscript c'est une suite de blocs : paragraphes, citations, listes à puces, titres par exemple. La fin d'un bloc est soit marquée explicitement par la syntaxe (comme les citations qui se terminent toutes par >>>), soit marquée par un retour à la ligne ou par une ligne vide. C'est important, donc soyez attentifs !

Beaucoup de blocs contiennent du texte interprété (par exemple les paragraphes ; mais pas les blocs de code, dont le contenu est recopié tel quel dans le HTML). Le texte interprété peut contenir des objets textuels, par exemple un passage de texte en gras, un lien hypertexte, ou une référence à un programme dans la base de données.

Passons maintenant aux réjouissances.

Détail des blocs

Les paragraphes sont exactement ce que vous pensez. Un paragraphe représente une unité de texte « par défaut », et se termine habituellement sur une ligne vide. Il peut contenir des retours à la ligne, qui sont alors fidèlement reproduits (ce qu'on fait actuellement dans la v42). Quand vous sautez une ligne, un nouveau paragraphe commence. Savoir si plusieurs lignes vides sont fusionnées en une seule n'est pas encore décidé !

Comme en Markdown, je vous propose deux styles de titre : soit avec des #, soit soulignés. Le premier type, c'est un ou plusieurs # suivis d'un paragraphe. Ça va donc jusqu'à la prochaine ligne vide. Le second type (décoratif), consiste en un paragraphe souligné par des = ou des -. La ligne qui souligne indique très naturellement la fin du bloc de titre.


Les citations et les blocs de code ont une syntaxe commune : ils commencent par trois symboles ouvrants sur une ligne (avec des options facultatives) et se terminent par trois symboles fermants sur une ligne. Les symboles doivent être placés au tout début de la ligne, sinon ça fait un paragraphe !


Niveau listes, je propose des listes à puces et des listes ordonnées. Pour les listes ordonnées, la numérotation commence par le nombre indiqué sur la première ligne puis incrémente les numéros en ignorant les valeurs suivantes (c'est classique) ; ça vous évite de tout renuméroter chaque fois que vous insérez un truc.


Il me reste les définitions de références. Parfois les liens de la forme [label](url) sont lourds à lire parce que l'URL est longue, parfois vous voulez utiliser plusieurs fois la même URL. Dans ce cas, vous pourrez écrire [label][ref-name] et définir plus loin la valeur de ref-name. C'est ce que j'appelle une définition de référence !


Une définition de référence tient sur une unique ligne. Je reviendrai sur ces liens dans la section suivante !

Les objets textuels

C'est là qu'on s'amuse à mettre n'importe quoi dans nos phrases. Commençons par les options de formatage :


Je pense que tout est à peu près explicite. Le cas `code`[langage] permet de mettre du code coloré dans une phrase. Il ne faut pas d'espace entre la backtick fermante et le premier crochet !

Les liens sont toujours une question délicate. La détection automatique des URLs dans les messages (autolinking) est compliquée à écrire et à utiliser, donc je vous propose de simplifier votre vie (et la mienne !) en mettant des chevrons (<url>). De façon générale, prenez le temps de mettre des noms sur vos liens, ce sera toujours supérieur !

Des liens, il y en a plusieurs types : certains sans noms, d'autres avec. En spécifiant un # au début de l'URL, vous pouvez référencer une section de votre article/tutoriel, ça enverra vers le titre associé !


Vous pouvez également décider de spécifier l'URL plus tard, à l'aide d'une référence (rappelez-vous, le bloc de définition de référence sert à ça !). Vous pouvez aussi utiliser une ressource (voyez plus loin) comme cible, ou tout simple une page de Casio Universal Wiki.


Comme avant, il y aura des médias. La syntaxe pour les utiliser est assez générale :


Je n'ai pas encore fixé le type de choses qu'on pourrait utiliser avec ; je vous invite à suggérer. Le comportement pourra être différent si cet objet est utilisé en plein milieu d'une phrase ou tout seul sur un paragraphe. Par exemple, on aura envie de centrer les images si elles sont toutes seules.

Viennent ensuite les spoilers. Les discussions ont été longues et compliquées. Pour tenter de concilier les partis, je vous propose un spoiler volontairement moins puissant que l'original. C'est un spoiler inline, et vous ne pouvez donc mettre que quelques phrases dedans. Vous pouvez le tester sur jsfiddle.net :



Il reste les choses les plus fun. D'abord les notes de bas de page (pour l'humour dans les articles en page d'accueil ^-^ ), et ensuite les références aux objets de Planète Casio :


Toutes les références de Planète Casio utiliseront la syntaxe :[a-z][^ :]+ (c'est-à-dire, ":" suivi d'une lettre minuscule suivi d'un mot non vide qui ne contient ni espace ni ":") et elle leur est strictement réservée. Cela n'interfère pas avec nos smileys !

On peut aussi utiliser ces références dans des liens (quand c'est approprié). Par exemple :


Vous avez aussi les mentions : de gens, ou de groupes. L'usage des mentions de groupe trop larges type @@all sera probablement réservé à l'équipe pour éviter des problèmes :


Il me reste, finalement, les smileys. Vous les connaissez assez bien pour ne pas avoir besoin d'une description. Je ne vous cache pas que j'aimerais bien remplacer les grands par des choses de taille raisonnable, ou les supprimer. Dans tous les cas, il y auras probablement de légères retouches de design sur les smileys habituels (presque rien).

Subtilités de syntaxe

Si vous n'avez pas envie de vous casser la tête, sautez cette section. Si vous pensez que la syntaxe ne va pas tenir le coup, lisez-la ; vous aurez peut-être des réponses. Si non, prévenez-moi dans les commentaires !

Pour le formatage des objets textuels, vous pouvez avoir envie de mettre un backtick dans le code. Pour ça, doublez les backticks sur le côté. Tout ce qu'il faut c'est que le code intérieur ne contienne pas la marque de fin. S'il apparaît des backticks, mais pas en même nombre, ce n'est pas grave :


Pour le gras et l'italique, c'est pareil, sauf qu'une fois tous les comptes terminés c'est la parité du nombre d'étoiles qui détermine le type de formatage que vous demandez (impair : emphasis, pair : strong). Ça marche aussi pour les citations imbriquées (et le code, comme vous vous en doutez) :


Je prévois que le bouton « Citer » calcule automatiquement un nombre satisfaisant de chevrons si le message à citer contient lui-même des citations. Faut pas déconner non plus !

Éléments à potentiellement ajouter

J'en ai déjà cité quelques-uns. Il me vient à l'esprit :

– De quoi centrer ou justifier le texte (paramètre du message)
– Des tableaux pour faire des statistiques *o*
– Les barres horizontales (facile à faire ça)

Éléments intentionnellement omis

Avec les discussions, j'ai mis à jour cette section. Voilà ce qui en reste ; les objets qui sont pour l'instant éliminés... avec explications.

Les spoilers ont été réduits à des objets inlines pour éviter qu'ils soient utilisés pour structurer les descriptions de programmes ou des grosses docs qui devraient être séparées en plusieurs pages. Le gameplay d'un jeu ne devrait pas être caché dans une boîte ! C'est le plus important. Les titres sont plus appropriés pour structurer et les grandes images seront redimensionnées automatiquement, donc cette restriction ne devrait pas gêner outre mesure. J'ai pu oublier des cas.

Le soulignement et le texte barré sont rarement utilisés. Le gras remplit efficacement le rôle de mise en avant prévu par le soulignement, et comme Lightscript ne précise pas ce que <strong> donne comme formatage, on peut aussi opter pour italique/soulignement sans gras. Le texte barré est difficile à lire. Honnêtement, j'ai surtout éliminé ces deux-là pour des raisons de syntaxe. J'ai eu trop de mal à trouver des moyens honnêtes de les introduire dans la définition du langage.

Les liens vers une page de profil et les barres de progression étaient compliqués à intégrer à la syntaxe, mais je peux réfléchir au premier avec la syntaxe réservée, par exemple :uLephenixnoir. Le second n'a à ma connaissance jamais été utilisé de façon productive, à part pour poster des commentaires de programmes qui balançaient un chiffre au lieu de donner des éléments intéressants sur l'état de développement des projets. On s'en passera sans peine, je pense.

Conclusion

C'est un très long post, je vous remercie de l'avoir lu jusque-là. Vous avez certainement des remarques à faire : j'y répondrai de mon mieux. Merci de votre aide !