Re: C’est reparti

[Valentin Villenave]

On 3/27/19, Jean-Christophe <address@hidden> wrote:
> Quelqu'un
> a-t-il décidé que seules les (anciennes) commandes les moins utilisées (
> partCombine ou autoChange ) pouvaient être normalisées ?

C’est un peu plus subtil : \addlyrics, \lyricsto, \drummode etc. ne
sont en fait pas des commandes au sens où nous l’entendons
habituellement (à savoir des variables LilyPond ou des fonctions
Scheme), mais des "balises" (tokens) reconnues en amont par le parser.

En d’autres termes, ce ne sont pas des commandes qui permettent
d’effectuer des manipulations sur des expressions, mais des mots-clés
qui permettent de _saisir_ lesdites expressions en premier lieu. En
conséquence de quoi, notamment, ils ne peuvent pas être redéfinis :

%% Ceci marche…

tuplet = { b }
{ \tuplet }

clef = { b }
{ \clef }

%% Et même ceci…

relative = { b }
{ \relative }

%% … Mais pas ceci :

lyricmode = { b }
{ \lyricmode }

> Pourquoi ne pas
> faire la proposition ? le pire qui puisse lui arriver est qu'elle soit
> refusée...

Je vais essayer.
Je trouve personnellement qu’il y a une certaine cohérence à ce que
tous les jetons du parseur soient en bas de casse, mais c’est parce
que je suis habitué au fonctionnement interne de LilyPond (et aux
différentes colorations syntaxiques de Frescobaldi :-)
Mais du point de vue d’un utilisateur plus frais, je peux comprendre
qu’on puisse trouver cohérent d’avoir \scaleDurations, \partCombine et
\addLyrics.

> Je pense entre nous qu'il est parfaitement possible de
> maintenir les deux syntaxes actives, puis retirer l'ancienne dans une
> vingtaine d'années ! :o))

Le fait que ces éléments de syntaxe soient traités par le parseur et
non par tout ce qui suit (LilyPond et Scheme) rend techniquement plus
difficile (voire franchement bordélique) l’idée de prendre en charge
l’une et l’autre syntaxe.

Du reste, cela n’est pas vraiment notre façon de faire : il est trop
difficile de continuer à supporter deux syntaxes, et le jour où l’on
abandonne la précédente est tout aussi mal vécu par un grand nombre de
gens que si on l’avait fait directement une bonne fois pour toutes.
(Une exception notable étant l’ancienne syntaxe pour \language, que
j’ai continué à supporter discrètement parce que je craignais que la
conversion soit trop hasardeuse ; un de ces jours il faudra que je m’y
replonge.) De surcroît, comme le but a toujours été d’encourager les
gens à utiliser convert-ly systématiquement, c’est plutôt mieux
d’annoncer clairement la couleur et de les obliger à se débrouiller.

En tout cas vu le chaos que ça ne manquerait pas de générer, il
faudrait attendre un changement de version majeure… c’est-à-dire
LilyPond 2.22, ou même plus volontiers LilyPond 3.0.

V.