Deprecation of LaTeX commands in songs

Question

Deprecation of LaTeX commands in songs

Closed this issue 9 years ago · 43 comments

Comme évoqué en #17 et #18, certaines commandes ne sont pas supportées par chordpro.
Ce sujet vise à décider de leur avenir.

Voici mon implémentation actuelle (dans le convertisseur JavaScript):

Commandes simples

\dots (et variantes): convertis en ... (trois points)
\shrp (et variantes): convertis en #
\oe : convertis en œ (vive l'UTF8)
\ier, \ieme : convertis en ier et ieme
\og, \fg (guillemets français): convertis en (accents de github pour le code) et''
\flt : convertis en &
\&, \_, \%, \#, \', \,, \ sont inchangés (suppression du backslash)
\{, \}, \newline, \MultiwordChords, \Adlib sont supprimés
\emph seul le contenu est conservé
equations $H_2O$ , $CO2$ , $5m^2$ convertis en H2O, CO2, 5m²
\Intro, \Chorus, \Bridge, \Verse, \Rythm, \Outro, \Solo, \Pattern sont inchangés (suppression du backslash)

Commandes de Header

title
album
artist
url
original
cover
lang
columns
tab
utab

Commandes de block

chorus transformé en start/end_of_chorus
bridge transformé en start/end_of_bridge
verse et verse* seul le contenu est conservé
repeatedchords seul le contenu est conservé
nolyrics seul le contenu est conservé
musicnote transformé en start/end_of_musicnote
textnote transformé en start/end_of_textnote
scripture transformé en start/end_of_scripture
echo transformé en {echo: blabla}

Answer 1 · 2015-07-18T16:52:10.000Z

\dots (et variantes): convertis en ... (trois points)

On peut utiliser … (vive l'utf8)

\shrp (et variantes): convertis en #

On peut utiliser ♯ (vive l'utf8)

\ier, \ieme : convertis en ier et ieme

Je propse ᵉʳ, ᵉ (vive l'utf8)

\og, \fg (guillemets français): convertis en (accents de github pour le code) et ''

Je propose « et ».

\&, \_, \%, \#, \', \,, \ sont inchangés (suppression du backslash)

Pourquoi pas une espace insécable ?

\Intro, \Chorus, \Bridge, \Verse, \Rythm, \Outro, \Solo, \Pattern sont inchangés (suppression du backslash)

Est-ce que ces commandes affichent quelque chose à l'écran ? Si oui, on peut utiliser des commentaires.

Avec tout cet UTF8, LaTeX risque de ne pas être content. J'avais fait en sorte que ça marche quand même dans la documentation ; il faudrait que je retrouve ça.

Pour verse*, il faudrait plutôt coller le contenu au verse précédent, sans quoi on va casser la numérotation des couplets.

Answer 2 · 2015-07-18T18:00:42.000Z

Avec tout cet UTF8, LaTeX risque de ne pas être content. J'avais fait en sorte que ça marche quand même dans la documentation ; il faudrait que je retrouve ça.

C'est la commande \DeclareUnicodeCharacter.

Answer 3 · 2015-07-18T21:15:52.000Z

\dots (et variantes): convertis en ... (trois points)

\shrp (et variantes): convertis en #

On peut utiliser ♯ (vive l'utf8)

Je préférerai le remplacer juste avant la compilation LaTeX (# est quand même beaucoup plus facile à saisir au clavier)

\og, \fg (guillemets français): convertis en (accents de github pour le code) et ''

Je propose « et ».

Ca marche (mais on pourrait aussi remplacer ces guillemets à la compilation)

\&, \_, \%, \#, \', \,, \ sont inchangés (suppression du backslash)

Ok pour l'espace insécable (j'avoue ne pas y avoir pensé - même si je pense que ça ne changera pas grand chose).

\Intro, \Chorus, \Bridge, \Verse, \Rythm, \Outro, \Solo, \Pattern sont inchangés (suppression du backslash)

\ier, \ieme : convertis en ier et ieme

En fait avec Outro & co., c'est plus les "annotations" qui sont remises en cause (cela concerne aussi \er). En effet, dans certains chants, il est indiqué l'ordre des couplets/des bridges (surtout quand il y a plusieurs couplets).

Pour verse*, il faudrait plutôt coller le contenu au verse précédent, sans quoi on va casser la numérotation des couplets.

C'est pas facile à implémenter dans le parseur, mais je peux insérer un {start/end_of_verse_} pour faciliter un post-traitement (par exemple, comment réagir si ce verse_ est juste après un chorus?).

Answer 4 · 2015-07-19T08:25:21.000Z

\dots (et variantes): convertis en ... (trois points)

\shrp (et variantes): convertis en #

On peut utiliser ♯ (vive l'utf8)

Je préférerai le remplacer juste avant la compilation LaTeX (# est quand même beaucoup plus facile à saisir au clavier)

À ma connaissance, # n'est pas utilisé d'une autre manière en LaTeX, donc ça me va.

\og, \fg (guillemets français): convertis en (accents de github pour le code) et ''

Je propose « et ».

Ca marche (mais on pourrait aussi remplacer ces guillemets à la compilation)

Le problème en utilisant `` et '', c'est qu'en LaTeX, ces guillements deviennent des guillements anglais. Donc avec ta solution, on ne pourrait pas avoir dans un même document des guillemets français et anglais (ce qui est nécessaire si on a à la fois des chants en anglais et en français).

Pour verse*, il faudrait plutôt coller le contenu au verse précédent, sans quoi on va casser la numérotation des couplets.

C'est pas facile à implémenter dans le parseur, mais je peux insérer un {start/end_of_verse_} pour faciliter un post-traitement (par exemple, comment réagir si ce verse_ est juste après un chorus?).

Bonne chance ^^

Answer 5 · 2015-07-20T14:28:39.000Z

En fait on peut déjà distinguer deux catégories: les caractères spéciaux (vive l'UTF8 ^^) et le reste (echo, bridge, verse*...).

Concernant les caractères spéciaux:

je suis assez partant pour convertir en caractères "simples" (genre ...) dans la base de données, et effectuer un pré-traitement (pour le convertir en … ou en \dots) lors de la génération du document qui sera ensuite rendu par LaTeX en pdf.
on peut toujours autoriser les caractères UTF8 dans les fichiers chordpro (sans garantie concernant le support effectif par LaTeX).

=> Question: quel doit être le comportement conseillé ? (ie. que doit faire le script de conversion)
Personnellement, je favoriserais plutôt ce qui est aisément saisissable au clavier (1er point)

Answer 6 · 2015-07-20T16:28:32.000Z

Pour la gestion des verse/verse*, j'ai eu une autre idée: se servir des retour chariots.
Si un couplet est précédé par 2 retours chariots, c'est un verse (numéroté), sinon c'est un verse* (non numéroté).

Answer 7 · 2015-07-20T16:35:15.000Z

je suis assez partant pour convertir en caractères "simples" (genre ...) dans la base de données, et effectuer un pré-traitement (pour le convertir en … ou en \dots) lors de la génération du document qui sera ensuite rendu par LaTeX en pdf.

Pour les points de suspension, pourquoi pas, mais pour les guillemets français « », je ne comprends pas ce que tu veux faire, sans perte d'information.

on peut toujours autoriser les caractères UTF8 dans les fichiers chordpro (sans garantie concernant le support effectif par LaTeX).

Effectivement, mais il faudra essayer de donner un message d'erreur compréhensible à l'utilisateur (surtout pour patanet, où l'utilisateur n'a qu'un contrôle très limité sur la compilation).

Pour la gestion des verse/verse*, j'ai eu une autre idée: se servir des retour chariots.

C'est très intéressant dans la mesure où les fichiers seront toujours lisibles par d'autres outils (avec éventuellement des erreurs de numérotation)… À voir…

Answer 8 · 2015-07-20T16:39:01.000Z

guillemets français

Désolé, j'ai oublié de précisé que j'avais implémenté ta proposition de garder les guillemets français (b0c7720)

verse/verse*

Toutes les implémentation de chordpro que j'ai vu jusqu'à présent ne numérotaient pas les couplets.
Et ça à l'avantage que le format texte-brut est assez proche du format compilé (et que ça ne casse pas de compatibilité potentiel)

Answer 9 · 2015-07-21T12:53:18.000Z

Pour éviter de me perdre dans les détails de conversion LaTeX -> ChordPro, j'ai commencé à rédiger une page du wiki concernant le format que Patacrep attend en entrée: https://github.com/patacrep/patadata/wiki/Chrodpro-format.
N'hésite pas à corriger si l'implémentation décidée diffère!

Answer 10 · 2015-07-22T08:26:18.000Z

Il y a sûrement des choses à merger depuis : https://github.com/patacrep/patacrep/wiki/chordpro

Answer 11 · 2015-07-22T09:09:15.000Z

@paternal : c'est cool, une grosse partie du travail a donc déjà été faîte!
Il reste à obtenir un consensus sur l'ensemble du format que l'on veut utiliser (notamment concernant les artistes multiples ou non)

Answer 12 · 2015-07-22T09:47:08.000Z

Il reste à obtenir un consensus sur l'ensemble du format que l'on veut utiliser (notamment concernant les artistes multiples ou non)

Pour le moment, vu que j'ai implémenté l'analyseur, j'ai imposé ma solution préférée. Mais c'est réversible si vous votez contre ^^. Donc pour le moment, c'est :

Plusieurs balises artist sont permises : {artist: Georges Brassens} {artist: Jean Boyer}
Chaque balise artiste est interprétée comme le champ by de \beginsong, et configurable dans le fichier .sb (voir la section auteur) : {artist:Paroles et musique de Jean Boyer, chantée par Brassens}…

Answer 13 · 2015-07-24T09:05:52.000Z

Ok, ça me convient pour les artistes.
(J'aime bien aussi l'idée de http://onsongapp.com/docs/features/formats/chordpro/: les artistes sont séparés par des ;)

Answer 14 · 2015-07-25T22:10:59.000Z

(J'aime bien aussi l'idée de http://onsongapp.com/docs/features/formats/chordpro/: les artistes sont séparés par des ;)

Il suffit d'ajouter ; à la liste des séparateurs. Ça pourrait être intelligent de le faire par défaut (si ça n'est pas déjà le cas).

Answer 15 · 2015-07-28T12:07:32.000Z

si ça n'est pas déjà le cas

Vraisemblablemt ce n'est pas encore le cas:
https://github.com/patacrep/patacrep/blob/master/patacrep/authors.py#L31

J'ai complété le wiki: la partie concernant le header est complète (mise à part la balise vcover que je ne comprends pas trop).

Par ailleurs {meta:key:value} peut-il apparaitre n'importe ou dans le chant, ou est-ce qu'il appartient au "header" ?

Answer 16 · 2015-07-28T19:19:39.000Z

si ça n'est pas déjà le cas

Vraisemblablemt ce n'est pas encore le cas:
https://github.com/patacrep/patacrep/blob/master/patacrep/authors.py#L31

Corrigé

J'ai complété le wiki: la partie concernant le header est complète (mise à part la balise vcover que je ne comprends pas trop).

vcover est un raccourci de vanilla cover. C'est peut-être un mauvais nom ; il est toujours possible de le changer. Cela implémente l'ancien comportement de cover, à savoir :

l'argument de cover est un fichier situé dans le même répertoire que la chanson ;
l'argument de vcover est un fichier situé là où LaTeX va chercher ses images normalement.

En écrivant cela, je me dis que cette distinction est peut-être spécifique à LaTeX, et qu'il faudrait peut-être ne laisser que cover en chordpro. Ensuite, l'interpréteur :

transforme celui-ci en vcover si le fichier n'est pas dans le même répertoire que la chanson ;
transforme celui-ci en cover si le fichier est dans le même répertoire que la chanson.

C'est à réfléchir ; c'est un peu trop vite dit : avec ce que j'ai dans la tête, il risque d'y avoir des conflits.

Par ailleurs {meta:key:value} peut-il apparaitre n'importe ou dans le chant, ou est-ce qu'il appartient au "header" ?

Si je ne me plante pas, il n'y a pas de header : pour nous humains, il est plus clair si les méta-informations sont en tête de fichier, mais lors de l'analyse, n'importe quelle info peut être n'importe où : cela ne pose aucun problème.

Answer 17 · 2015-07-28T19:30:16.000Z

Corrigé

Parfait, merci!

vcover

Outre le problème des chemins (relatifs, absolus - qu'il est effectivement préférable de gérer dans l'interpréteur), il s'agit aussi de savoir si on autorise l'inclusion d'images dans les chants (je suis plutôt contre, au moins dans un premier temps: on a assez de problèmes comme cela^^)

{meta:key:value}

En fait ma question est de savoir si sa position dans le fichier est importante ou non.
Par exemple, {title: Titre} peut être placé n'importe où, mais déplacer {start_of_chorus} sera génant par exemple.
En relisant ta réponse, tu qualifies cela de "méta-information", donc je suppose que la position n'est pas importante (mais préférable en début de fichiers, pour nous pauvres humains^^)
[Du coup ce que j'appelle header sont toutes ces méta-informations dont la position n'est pas importante]

Answer 18 · 2015-07-28T21:57:12.000Z

vcover
Outre le problème des chemins (relatifs, absolus - qu'il est effectivement préférable de gérer dans l'interpréteur), il s'agit aussi de savoir si on autorise l'inclusion d'images dans les chants (je suis plutôt contre, au moins dans un premier temps: on a assez de problèmes comme cela^^)

Je dirais bien : on laisse cover et vcover en LaTeX (dans ce langage, le vcover est plus « naturel »), mais on supprime vcover pour ne garder que cover en chordpro (c'est un langage de plus haut niveau).

Enfin, tout ça, c'est pour patacrep. Pour la version web, faites ce que vous pouvez…

{meta:key:value}
En fait ma question est de savoir si sa position dans le fichier est importante ou non.
Par exemple, {title: Titre} peut être placé n'importe où, mais déplacer {start_of_chorus} sera génant par exemple.
En relisant ta réponse, tu qualifies cela de "méta-information", donc je suppose que la position n'est pas importante (mais préférable en début de fichiers, pour nous pauvres humains^^)
[Du coup ce que j'appelle header sont toutes ces méta-informations dont la position n'est pas importante]

C'est ça.

Answer 19 · 2015-07-29T06:18:48.000Z

Cela me convient parfaitement 👍

Je compte ensuite m'attaquer à ce que j'ai nommer les "song block" (couplet, refrain, bridge & co.), mais je pense que je vais créer une autre issue (celle-là commence à être déjà bien longue ^^)

Answer 20 · 2015-07-29T13:41:58.000Z

Du coup on peut continuer sur notre lancée et valider le reste de https://github.com/patacrep/patacrep/wiki/chordpro.

Je suis ok pour:

title, subtitle (multiples)
language (unique : langue principale)
album (multiple ?)
copyright (multiple ?)
columns (unique)
# commentaire (et du coup supprimer encoding)

Answer 21 · 2015-07-29T15:49:52.000Z

album (multiple ?)

Le paquet LaTeX songs n'accepte qu'un seul album. Après, on peut bidouiller, mais est-ce vraiment nécessaire (temps de travail vs utilité) ?

copyright (multiple ?)

Le paquet LaTeX songs n'accepte qu'un seul copyright. Libre à l'utilisateur de mettre tout le texte qu'il veut dedans (exemple : {copyright: Double licence CC-by-sa 3.0 et Art libre}).

# commentaire (et du coup supprimer encoding)

Il me semble qu'on avait tranché cela quelque part en disant :

si un encodage est précisé dans le fichier .sb, on lit tous les fichiers avec cet encodage ;
sinon, on devine.

Dans tous les cas, cette idée de définir l'encodage de chaque fichier avait été abandonnée (trop compliquée à mettre en place tant qu'on n'en a pas besoin).

Et pour patanet, je pense que l'utf8, c'est bien.

Answer 22 · 2015-07-29T20:46:38.000Z

L'unicité de l'album et du copyright me conviennent parfaitement

Et pour patanet, je pense que l'utf8, c'est bien.

Je pense qu'effectivement, on ne va pas essayer de se compliquer la vie tout de suite^^

je pars en camp scout pendant une semaine : tu as donc le droit à une pause (bien méritée) de mes nombreuses questions ^^

Answer 23 · 2015-08-05T12:03:49.000Z

Pour la gestion des verse/verse*, j'ai eu une autre idée: se servir des retour chariots.
C'est très intéressant dans la mesure où les fichiers seront toujours lisibles par d'autres outils (avec éventuellement des erreurs de numérotation)… À voir…

C'est le genre de truc invisible et insupportable en Markdown. Je préfèrerai supprimer complètement les verse*, quitte à remplacer par des start_of_bridge. bridge a une valeur sémantique que verse* ne possède pas.

Answer 24 · 2015-08-05T13:13:54.000Z

insupportable

Qui t'énerve, ou qu'il n'est pas possible d'implémenter ?

Answer 25 · 2015-08-05T15:31:41.000Z

Qui t'énerve, ou qu'il n'est pas possible d'implémenter ?

Qui m'énerve ^^. Surtout parce que les contrôles à base de lignes blanches ne sont pas intuitifs ("mais pourquoi j'ai pas de numéro ici ????" — "Tu as deux lignes blanches, donc c'est un verse*" — "un quoi ?").

Answer 26 · 2015-08-08T12:17:48.000Z

J'ai effectivement l'impression qu'abandonner la possibilité de sauter des lignes dans un couplet est la meilleure solution… Ceux qui veulent vraiment faire cela utiliseront LaTeX…

Answer 27 · 2015-08-11T09:26:02.000Z

Surtout parce que les contrôles à base de lignes blanches ne sont pas intuitifs

Effectivement, je partage assez ce point de vue.

En revanche, concernant la numérotation des couplets parmi tous les logiciels que j'ai vu jusqu'à présent, aucun ne numérote les couplets.

Je pense que la numérotation des couplets devraient être conservé dans patacrep, et c'est pour cela que j'ai proposé cette solution hybride:

si un couplet et précédé d'au moins 2 sauts de ligne alors il est numéroté (on pourrait aussi imaginé quelque chose à base de commentaires).

Certes, cela créé un contrôle à base de lignes blanches, mais le résultat "compilé" est visuellement assez proche du texte brut (les verse* ont un espacement réduit avec le paragraphe précédent).

Par ailleurs, je ne sais pas combien de personnes écriront directement du texte brut (patanet par exemple aura une interface plus WYSIWYG) et l'on peut s'arranger pour que la numérotation soit le seul "contrôle invisible" du format SongPro de patacrep.

Ceux qui veulent vraiment faire cela utiliseront LaTeX

J'aimerai bien que cela soit accessible via patanet (où LaTeX est prohibé dans l'interface utilisateur)

Answer 28 · 2015-08-11T15:48:24.000Z

Je pense que la numérotation des couplets devraient être conservé dans patacrep, et c'est pour cela que j'ai proposé cette solution hybride:

L'idée ici n'est pas d'abandonner la numérotation, mais la capacité à sauter des lignes au sein d'un couplet.

Answer 29 · 2015-08-11T19:51:22.000Z

L'idée ici n'est pas d'abandonner la numérotation, mais la capacité à sauter des lignes au sein d'un couplet.

Au temps pour moi. Dans ce cas, le verse* devient un verse ou est-ce qu'on essaye de le fusionner avec un autre verse ?
(je reste tout de même favorable à la solution des sauts de lignes multiples ou simples)

Answer 30 · 2015-08-11T19:57:07.000Z

Au temps pour moi. Dans ce cas, le verse* devient un verse ou est-ce qu'on essaye de le fusionner avec un autre verse ?

Dans ce cas, pour ne pas casser la numérotation, les verse* seraient collés au verse précédent.

Pour le saut de ligne, ça m'attriste de dire ça, mais je ne vois pas de solution élégante, qui n'innove pas trop par rapport à ce qui existe déjà.

Answer 31 · 2015-08-12T07:16:03.000Z

Je propose l'expérimentation suivante :

On implémente la gestion des sauts de lignes multiples et simples dans un premier temps
Si cela génère trop de confusion on supprime cette fonctionnalité (relativement aisé : les sauts de lignes doubles sont remplacés par des sauts de lignes simples)

La démarche inverse (Implémenter ce saut de ligne à postériori) me semble impossible (comment séparer les verse en verse* ?)

Je reconnais que dans ce cas, je suis un peu "le mec qui veut absolument une fonctionnalité qui ne fait pas l'unanimité", mais je suis prêt à implémenter cette fonctionnalité dans le convertisseur JavaScript (directement utilisable en ligne depuis le navigateur).

En revanche j'aurai besoin d'aide pour l'implémentation côté patacrep (python), donc en l'absence de soutien, je devrais abandonner cette idée.

Answer 32 · 2015-08-17T16:41:15.000Z

Le problème avec cette manière de faire est qu'il est très difficile de revenir en arrière et de supprimer une syntaxe qui a déjà été supportée.

Plus globalement, je ne suis pas sûr de comprendre quel est le problème ici ...

Answer 33 · 2015-08-17T20:15:17.000Z

Le problème avec cette manière de faire est qu'il est très difficile de revenir en arrière et de supprimer une syntaxe qui a déjà été supportée.

Je ne suis pas sûr de comprendre : "une syntaxe qui a déjà été supportée", c'est à propos de LaTex verse* ou de ma proposition ? (en fait ma proposition n'offre qu'un sursis à cette fonctionnalité : dans tous les cas si on la supprime, on vas devoir gérer des cas à la main)

Plus globalement, je ne suis pas sûr de comprendre quel est le problème ici ...

Pour moi, il s'agit de savoir que faire des verse* (je suis partisan de les conserver) et si on les supprimer, comment on fait (fusion avec le verse précédent me parait le plus naturel)

Answer 34 · 2015-08-19T20:31:07.000Z

Je ne suis pas sûr de comprendre : "une syntaxe qui a déjà été supportée", c'est à propos de LaTex verse* ou de ma proposition ? (en fait ma proposition n'offre qu'un sursis à cette fonctionnalité : dans tous les cas si on la supprime, on vas devoir gérer des cas à la main)

À propos de ta proposition. Il sera compliqué de supprimer la possibilité de sauter des lignes dans un chant au format ChordPro si cette possibilité a été un jour proposée.

Pour moi, il s'agit de savoir que faire des verse* (je suis partisan de les conserver) et si on les supprimer, comment on fait (fusion avec le verse précédent me parait le plus naturel)

Je suis plutôt partisant de les supprimer. Les verse* contiennent des informations de mise en page (pas de numérotation) qui n'ont pas leur place dans un format descriptif. Ils ont pour moi deux usages :

Avoir un couplet sans numérotation => C'est un bridge.
Sauter des lignes dans les couplets.

Pour gérer ce dernier cas, pourquoi ne pas ajouter une balise ChordPro de type {meta: layout: newline} ou plus proche de chordii de la forme {new_line} ?

Answer 35 · 2015-08-19T21:00:07.000Z

Je suis assez d'accord avec ton analyse : je considère effectivement les verse* comme des bridge ou des sauts de ligne dans les couplets.

Mais on peut quand même proposer une implémentation à base de saut de ligne ;-)

Ma proposition d'implémentation en résumé (à mon avis, forcément biaisé ^^):

Avantages

c'est facile à écrire (pour avoir un saut de ligne, il suffit de faire un saut de ligne)
le script de conversion est pas trop tordu (<= argument de flemmard, je reconnais)
le texte brut est assez proche du résultat final
la plupart des autres logiciel ChordPro ne numérotent pas les couplets (et font seulement des sauts de ligne simple), donc leur formatage serait assez bien respecté

Inconvénients

cela impose 2 saut de ligne avant un "vrai" couplet
ce contrôle n'est pas très naturel et peux générer de la confusion pour les utilisateurs ("mais pourquoi il ne numérote pas ce couplet, ce $#@! logiciel")

Quelque soit le choix, je pense qu'il sera possible de changer à postériori (soit en changeant les {new_line} en saut de ligne, soit en les insérent lorsque le saut de ligne est unique).

Answer 36 · 2015-09-02T10:42:40.000Z

Si on valide un {newline}, on peut l'utiliser avant même qu'il soit implémenté. Dans le couplet suivant :

Première [A]ligne
[B#]Second ligne
{newline}
[D]Début de la [B4]deuxième partie
[E]Fin

la directive {newline}, non-implémentée, serait simplement ignorée, et on obtient, dans un premier temps, un couplet sans saut de ligne, et quand on implémentera le {newline}, un couplet avec saut de ligne.

Answer 37 · 2015-09-02T13:21:53.000Z

c'est facile à écrire (pour avoir un saut de ligne, il suffit de faire un saut de ligne)

Les sauts de lignes ont déjà une sémantique en ChordPro : c'est le passage à un autre couplet. Donc cette solution change la sémantique des fichiers d'entrée.

Si on valide un {newline}, on peut l'utiliser avant même qu'il soit implémenté.

C'est pas mal ça !

Answer 38 · 2015-09-11T15:02:33.000Z

Ok, va pour le {newline} (avec ou sans _ ?)

Answer 39 · 2015-09-11T15:14:02.000Z

Je préfère la version sans _, mais d'autres directives ChordPro utilise le format {new_***}.

Answer 40 · 2015-09-11T15:27:26.000Z

Apparemment c'est un seul mot (à la différence line break).
Je soutien aussi sans le _

Answer 41 · 2015-09-11T15:57:06.000Z

Apparemment c'est un seul mot (à la différence line break).

Vendu pour moi !

Answer 42 · 2015-09-11T16:47:53.000Z

Implémenté dans 57e7fdf !

Politique de fusion appliquée:

si un verse* est juste après un verse, il est fusionné avec celui-ci
sinon, si un verse* est juste avant un verse, il est fusionné avec celui-ci
sinon, il est transformé en verse (<= je préfère ne pas faire de bridge, parce qu'en vrai il y a plein de cas particuliers...)

Answer 43 · 2015-10-12T13:57:43.000Z

Suite (de préférence plus structurée) dans #22