-- Leo's gemini proxy
-- Connecting to unbon.cafe:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Particulièrement intéressé par la cuisine, il m’a toujours été compliqué de retenir et partager les recettes. De plus, bien qu’ayant un certain cachet, les livres de recettes sont plus encombrants qu’autre chose et poussent à l’éparpillement des ressources. La numérisation et/ou standardification me paraît être fort utile. En naviguant sur Internet, je suis tombé par hasard sur le Cooklang, un langage de balisage (comme le MarkDown) ayant ce but. Voyant que sa syntaxe était prise en charge par de nombreux éditeurs dont ne faisait pas partie nano et ayant beaucoup trop de temps à tuer, j’ai décidé d’analysé la spécification du langage et réaliser un fichier nanorc en utilisant des RegExp.
Cooklang[1] est un langage lisible, simple et permettant de numériser des recettes de manière « intelligente ». Son utilisation vise a « simplifier la gestion des recettes » et « faciliter la planification des courses ». Dans la lignée du PlainText, le projet défini le format .cook dont la structure repose sur cinq éléments : les métadonnées (ex : nom, date, portions, etc.), les ingrédients, les ustensiles, les temps et les commentaires. Pour cela, six formes de balises sont utilisées comme suit :
>>Ceci est une ligne de métadonnée
@Ceci est un ingrédient{}
#Ceci est un ustensile{}
~Ceci est un temps{}
--Ceci est une ligne de commentaire
[-Ceci est un bloc de commentaire-]
Particulièrement simple, le langage offre une grande lisibilité pour la personne à l’écran tout en permettant des fonctions de traitement. Les différentes balises définissent des types d’éléments dont qu’il est possible d’extraire aisément du fichier pour en sortir des fiches standardisées avec le temps, les ustensiles et les ingrédients requis, voire en faire une liste de course. Parmi les applications possibles, sont actuellement disponibles une application en ligne de commande[3] ainsi que sur iOS[4].
Cooklang n’est pas la seule initiative dans son domaine et il existe des alternatives qui, bien que plus riches, sont également plus lourdes à prendre en charge. Parmis elles, sont cités le microformat h-recipe[5] ainsi que le schéma Recipe[6]. Tous deux sont des structures de données traitant visant également les recettes de cuisine. Pour autant, leur spécification me rebute tant il y a de paramètres possibles. Aussi, il ne semble pas y avoir d’exemple de balisage qui soit accessible pour d’autres que machines et technophiles.
nano[7] est éditeur de texte léger permettant la coloration syntaxique, Cooklang étant particulièrement clair à ce sujet, j’ai réalisé un fichier visant à sa prise en charge par l’éditeur. Bien qu’il soit possible de faire sans, la navigation au sein de codes serait particulièrement austère si ce n’était pour la fonction de coloration syntaxique des éditeurs de texte. Pour cela, un éditeur a besoin de connaitre les différents éléments définis par un format ainsi que les couleurs à attribuer. La prise en charge de Cooklang ést déjà faite pour les éditeurs les plus populaires[8], j’utilise personnellement nano[9] et c’est pourquoi j’ai décidé d’en étendre la prise en charge.
Pour ses paramètres, dont les règles de coloration, nano fait appel au fichier ~/.nanorc. Dans celui-ci, j’ai indiqué préférer que par défaut soient visibles les numéros de ligne, que le texte apparaisse sur plusieurs lignes s’il dépasse la taille de l’écran plutôt que de m’obliger à défiler horizontalement ainsi que l’emplacement où sera enregistré le ficher cooklang.nanorc où je place également les autres colorations syntaxiques allégrement copiés d’un dépot GitHub[10].
set linenumbers set softwrap include "~/.nano/cooklang.nanorc"
Vous retrouverez également le fichier cooklang.nanorc sur Codeberg[11]. À noter que c’est un premier jet qui est sûrement améliorable.
Le fichier est très léger et se compose d’une ligne de RegExp pour chaque élément défini par la spécification Cooklang. RegExp est une contraction de RegularExpression, une séquence de caractères permettant d’indiquer un masque de recherche. Pour cet usage relativement simple, il me suffit de définir une séquence pour chacun des éléments décrit plus haut. Ainsi, une ligne de métadonnée se décrit par une une ligne (^), commençant par deux caractères > (>>) et se terminant par un retour à la ligne (comportement par défaut de nano).
color yellow "^>>"
« color yellow » indique à nano que je souhaite que soit surligné en yellow (jaune) toute séquence répondant à la formule que j’ai demandée. Le même principe peut être appliqué pour les autres éléments qui ont un « caractère d’ouverture » et de « fermeture ».
En m’appuyant sur des modèles à disposition, j’ai développé une coloration syntaxique de Cooklang sur l’éditeur de texte nano. Plus par exercice que par réel besoin, j’ai tiré parti de la spécification détaillée du langage pour définir des séquences regexp correspondantes et ainsi faciliter la rédaction de fichiers .cook sous nano étendant à la fois le support de l’éditeur et du langage.
Un des défauts pour lequel je n’ai pas trouvé de solution élégante (et évidente), est pour les ingrédients et ustensiles sans crochets. Selon la spécification, il est possible qu’un de ces éléments soit défini sans crochets s’il n’est composé que d’un seul mot, ce qui est pratique dans les faits mais qui m’embête sérieusement pour la coloration. La piste que j’avais était de superposer des règles et couches de coloration de manière à ce que soit surligné toute séquence suivant @ ou # jusqu’à atteindre {, puis de désurligner (« color normal ») entre @, # et ~ avant d’enfin resurligner le mot suivant @ ou # ([@|#]\S*\>). Je n’ai malheureusement pas réussi à mettre en œuvre cette idée, n’arrivant pas à utiliser les formules dites « lookbehind » (?<=) ni ne comprenant comment faire sélectionner les éléments X1 et X2 entre y soit : yX1yX2y. La séquence testée (y\S*y) ne sélectionnant que X1 et pas X2. Le premier jet a tout de même été publié. Utilisable en l’état, il nécessite l’usage des crochets même pour un mot unique, je reste à l’écoute de toute suggestion me permettant de le faire répondre au mieux à la spécification.
Dans la lancée, j’ai souhaitais également réaliser un nanorc pour le gemtext, il se trouve que cela existe déjà[12].
-- Response ended
-- Page fetched on Sun May 19 02:50:59 2024