Subject: LilyPond 2.23.14, avec un appel à testeurs

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 00:13:57 +0200

Bonsoir à toutes et à tous,

En bon crieur public de service, j'ai le plaisir de vous annoncer la
parution de la version 2.23.14. C'est une version instable, la dernière
version stable étant la 2.22.2. Les binaires sont ici :

https://lilypond.org/development.fr.html

Les instructions d'installation ici :

https://lilypond.org/doc/v2.23/Documentation/learning/installing

La liste des changements ici en français :

https://lilypond.org/doc/v2.23/Documentation/changes/index.fr.html

et ici en anglais (la traduction française n'a pas encore
eu le temps d'intégrer les nouveautés très récentes) :

https://lilypond.org/doc/v2.23/Documentation/changes/index.html

Je rappelle qu'en passant à une nouvelle version, il faut
toujours passer convert-ly sur ses fichiers, pour faire toutes
les mises à jour de syntaxe nécessaires. Dans Frescobaldi,
c'est dans Outils > Mettre à jours avec convert-ly, et en ligne
de commande, il suffit d'utiliser la commande « convert-ly »,
sœur de la commande « lilypond ».

Voilà maintenant la partie la plus importante de ce message :
cette version a besoin de testeurs. En effet, si tout se
passe bien avec cette version, la suivante sera une version
bêta de la prochaine version stable, 2.24, ce qui signifie
notamment que la syntaxe et les fonctionnalités seront figées
afin de laisser aux gens (notamment aux codeurs Scheme) le
temps de se préparer. Seules les corrections de bug seront
intégrées à la version 2.24 à partir de ce moment-là, les nouvelles
fonctionnalités allant dans la 2.25 (instable). En particulier,
si des changements de syntaxe s'avéraient nécessaires pour régler
un bug, il est souhaitable que cela soit détecté le plus tôt
possible. Donc, si vous utilisez LilyPond sur des projets
importants, vous êtes fortement encouragé(e) à tester que
cette version fonctionne comme il se doit modulo les changements
qui sont voulus (qui sont décrits dans la liste des nouveautés
dont le lien est ci-dessus, et avec lesquels convert-ly
se débrouille souvent bien). Rappelons qu'il n'y a aucun problème
à avoir plusieurs versions en parallèle, vous pouvez tout à fait
installer celle-ci juste pour tester tout en restant en 2.22
pour vos projets.

Pour vous allécher, voici les quelques nouvelles fonctionnalités
les plus importantes dans cette version, ainsi que dans la 2.23.13
pour laquelle je n'avais pas fait d'annonce. Il y en a d'autres,
ainsi que des corrections de bugs comme d'habitude.

- Il y a une nouvelle option, « compile-scheme-code », qui utilise
   un mécanisme différent pour exécuter le code Scheme. Cela donne
   de meilleurs messages d'erreur, qui indiquent le numéro de ligne
   précis où l'erreur s'est produite, et pas juste le numéro de ligne
   de l'expression Scheme entière qui a conduit à l'erreur. Cela s'active
   soit en passant -dcompile-scheme-code en ligne de commande, soit en
   mettant au début du fichier .ly, avant tout code Scheme :

   #(ly:set-option 'compile-scheme-code)

   Par contre, il faut savoir qu'il y a quelques limitations, voir le tout
   dernier point de
https://lilypond.org/doc/v2.23/Documentation/changes/index.html

- La commande \caesura n'est plus limitée au grégorien mais sert
   désormais aussi aux césures modernes. Avec un simple \caesura,
   on obtient le signe de césure. Avec des retouches simples, il
   est possible d'obtenir d'autres genres de pauses. Par exemple,
   il était jusqu'ici compliqué de mettre des points d'orgue sur
   les barres de mesure (https://lsr.di.unimi.it/LSR/Item?id=10),
   alors qu'avec \caesura c'est un jeu d'enfant :

{
   c'1
   \once \set Staff.caesuraType = #'()
   \caesura ^\fermata _\fermata
}

   Pour plus d'infos :

https://lilypond.org/doc/v2.23/Documentation/notation/writing-rests#caesuras

- Suite notamment à des discussions avec Vincent, deux commandes ont
   fait leur apparition, \textMark et \textEndMark. Elles ajoutent des
   indications textuelles entre les notes, un peu comme \mark "truc" ou
   \mark \markup ..., sauf qu'elles sont plus adaptées pour le texte,
   par opposition aux repères A, B, C, ... L'une des différences est que
   \mark ne permet pas d'avoir plusieurs textes au même moment, sujet sur
   lequel Vincent a écrit un article détaillé :
   https://myrealbook.vintherine.org/double-marks.html
   Maintenant, avec \textMark et \textEndMark, les snippets doubleMark
   et polyMark ne sont plus nécessaires.

   Il y a d'autres différences, notamment le grob créé, qui est un
   TextMark au lieu d'un RehearsalMark.

   Pour plus d'infos :

https://lilypond.org/doc/v2.23/Documentation/notation/writing-text.html#text-marks

   (en anglais pour 2.23.14, mais la version française arrive déjà grâce
   à Jean-Charles Malahieude qui traduit plus vite que son ombre).

C'est tout, et c'est déjà bien assez. Bonnes LilyPonderies, et à
bientôt sur la liste,

Jean

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 10:59:48 +0200

Le 10/10/2022 à 00:13, Jean Abou Samra a écrit :

cette version a besoin de testeurs.

Bonjours à toutes et à tous

Je me suis donc installé un environnement de test et j'ai compilé sans autre changement qu'un convert-ly. Première erreur dans l'ordre des contenus pdf de la table des matières : le tocAct apparaît après le premier tocItem et non pas avant comme il se devrait.

Bonne semaine

--
Vincent Gay
Envoyé depuis mon saxo-phone :)
https://myrealbook.vintherine.org/ - http://photos.vintherine.org/

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 11:58:56 +0200

deux commandes ont  fait leur apparition, \textMark et \textEndMark.
J'ai testé ça dans tous les sens, empilés les eux sur les autres, avec des \tweak, avec des \override... Nickel. Maintenant je n'ai réellement plus besoins de polyMark (J'ai juste 120 fichiers à rectifier pour mon recueil 😠)

Juste une petite remarque à propos de la taille de la police par défaut : elle est équivalente à un simple \markup, inférieure à celle obtenue par un \mark \markup. Cela se règle aisément par un \override Score.TextMark.font-size = #2

---

From: Martial R <[email-masked]>
Date: Mon, 10 Oct 2022 12:00:45 +0200

Bonjour,
petite amélioration qui n'est pas indispensable, vu que Lily renvoie un bip
d'erreur !
 Lily criait déjà pour la version 13,  le convert-ly ne convertit pas (#')
en point (.)
exemple
  \override VerticalAxisGroup #'remove-first = ##t
n'est pas converti en
  \override VerticalAxisGroup.remove-first = ##t

Bonne journée et merci pour cette version 2.23.14

-- 
Martial Rameaux

---

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 12:47:44 +0200

> Le 10 oct. 2022 à 11:36, Vincent Gay <[email-masked]> a écrit :
> 

Je parie que tu as encore le code que je t’avais donné ici : https://lists.gnu.org/archive/html/lilypond-user-fr/2022-08/msg00078.html

C’est un contournement du bug qui inverse les items du contenu qui pointent vers un même page. Le contournement consiste à les réinverser. Or le bug a été réglé en 2.23.13, donc il suffit d’enlever le contournement qui réinverse et tout devrait rentrer dans l’ordre.

---

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 12:53:15 +0200

> Le 10 oct. 2022 à 11:59, Vincent Gay <[email-masked]> a écrit :
> 
> 
> J'ai testé ça dans tous les sens, empilés les eux sur les autres, avec des \tweak, avec des \override... Nickel. Maintenant je n'ai réellement plus besoins de polyMark

Super.

> (J'ai juste 120 fichiers à rectifier pour mon recueil 😠)

Ce qui favoriserait la cohérence mais n’est pas indispensable non plus, à ta place je ne suis pas sûr que je m’embêterais. Cela dit, en fonction de la manière dont tu as écrit ton code existant, peut-être que tu pourrais convertir une majorité des cas avec un script sed ou autre, et ainsi rendre la tâche moins grosse ?

> Juste une petite remarque à propos de la taille de la police par défaut : elle est équivalente à un simple \markup, inférieure à celle obtenue par un \mark \markup. Cela se règle aisément par un \o…

C’est voulu. Je trouvais que les RehearsalMark étaient trop grosses dans les cas comme « ad lib ». TextMark a une taille par défaut qui est quand même légèrement plus grosse que TextScript, mais effectivement nettement plus petite que RehearsalMark.

De toute façon, étant donné que ces nouvelles commandes peuvent servir à beaucoup de choses différentes, j’ai bien peur qu’il n’y ait pas de « bonne » valeur par défaut universelle.

---

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 13:09:24 +0200

> Le 10 oct. 2022 à 12:01, Martial R <[email-masked]> a écrit :
> 
> Bonjour, 
> petite amélioration qui n'est pas indispensable, vu que Lily renvoie un bip d'erreur ! 
>  Lily criait déjà pour la version 13,  le convert-ly ne convertit pas (#') en point (.) 
> exemple 

Bonjour,

Oui, ça a déjà été signalé sur la liste anglophone mais ça m’était sorti de la tête, merci de me le rappeler. L’affaire, c’est que la nouvelle syntaxe a été introduite il y a longtemps, dans la version 2.17.6, avec prise en charge dans convert-ly, tandis que la version 2.23.13 n’a ajouté qu’un avertissement sur l’ancienne syntaxe. On peut donc forcer convert-ly à faire cette conversion en faisant une mise à jour de 2.17.5 vers 2.17.6 :

convert-ly --from 2.17.5 --to 2.17.6 fichier.ly

Cordialement,
Jean

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 13:45:33 +0200

Le 10/10/2022 à 12:47, Jean Abou Samra a écrit :
> Je parie que tu as encore le code que je t’avais donné ici : 
> https://lists.gnu.org/archive/html/lilypond-user-fr/2022-08/msg00078.html

Arf... C'est encore plus bête que ça ! Pourquoi je ne sais pas mais je 
l'avais mis à 2 endroits : le fichier principal et un fichiers inclus. 
J'avais pensé à l'enlever mais il en restait un bien caché.

Du coup c'est tout bon, merci.

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 14:32:46 +0200

Le 10/10/2022 à 12:53, Jean Abou Samra a écrit :

J'ai juste 120 fichiers à rectifier pour mon recueil 😠)

Ce qui favoriserait la cohérence mais n’est pas indispensable non plus, à ta place je ne suis pas sûr que je m’embêterais.

Ben si, mon recueil devrait être prêt pour la fin de l'année, donc pouvoir être en 2.24. J'aimerai qu'il soit aussi "propre" que possible puisque les sources sont incluses. Immodestement ça me ferait plaisir qu'il constitue une bonne illustration de ce que l'on peut faire avec Lilypond dans le monde du Jazz.

Cela dit, en fonction de la manière dont tu as écrit ton code existant, peut-être que tu pourrais convertir une majorité des cas avec un script sed ou autre, et ainsi rendre la tâche moins grosse ?

Si je m'était comporté intelligemment partout de la même manière sans doute. Mais comme il s'agit de reprise de code datant, pour les plus vieux, de la 2.18 je retrouve plusieurs manière de traiter le même problème.

---

From: Martial R <[email-masked]>
Date: Mon, 10 Oct 2022 15:10:11 +0200

Merci,
impeccable dans Frescobaldi
Outils
mettre à jour avec convert-ly
Depuis la version 2.17.5
Vers la version 2.17.6
Mis à jour avec le  "."  et passage direct en version 2.23.14

Cordialement
-- 
Martial Rameaux

Le lun. 10 oct. 2022 à 13:09, Jean Abou Samra <[email-masked]> a écrit :

>
> Bonjour,
>
> Oui, ça a déjà été signalé sur la liste anglophone mais ça m’était sorti
> de la tête, merci de me le rappeler. L’affaire, c’est que la nouvelle
> syntaxe a été introduite il y a longtemps, dans la version 2.17.6, avec
> prise en charge dans convert-ly, tandis que la version 2.23.13 n’a ajouté
> qu’un avertissement sur l’ancienne syntaxe. On peut donc forcer convert-ly
> à faire cette conversion en faisant une mise à jour de 2.17.5 vers 2.17.6 :
>

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 15:31:26 +0200

Le 10/10/2022 à 11:58, Vincent Gay a écrit :

Une petite observation :

\textMark \markup 4x ça passe

\textMark "4x" ça passe

\textMark 4x ça coince

/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AGoGo.ly:54:16: Erreur : type d'argument erroné pour 1.

Attendait markup, 4 trouvé.

\textEndMark

4X

/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AGoGo.ly:54:17: Erreur : « X » n'est pas un nom de note

\textEndMark 4

X

erreur fatale : erreur sur les fichiers "/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.ly"

Arrêté avec le code de retour 1.

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 18:01:16 +0200

> Cela dit, en fonction de la manière dont tu as écrit ton code existant, peut-être que tu pourrais convertir une majorité des cas avec un script sed ou autre, et ainsi rendre la tâche moins grosse ?
En fait oui, sed et grep me font gagner beaucoup de temps

---

From: Denis Bitouzé <[email-masked]>
Date: Mon, 10 Oct 2022 18:36:27 +0200

Le 10/10/22 à 18h01, Vincent Gay a écrit :

>> Cela dit, en fonction de la manière dont tu as écrit ton code existant,
> peut-être que tu pourrais convertir une majorité des cas avec un script sed ou
> autre, et ainsi rendre la tâche moins grosse ?

Au passage, `ripgrep` (aka `rg`) te ferait gagner plus de temps que `grep` :

  ┌────
  │ $ find /home/bitouze/texlive/2022/texmf-dist/tex/latex/ -type f | wc -l
  │ 18902
  │ $ time grep -r 'french' /home/bitouze/texlive/2022/texmf-dist/tex/latex/
  │ [...]
  │ 0,22s user 0,34s system 16% cpu 3,319 total
  │ $ time rg 'french' /home/bitouze/texlive/2022/texmf-dist/tex/latex/
  │ [...]
  │ 0,13s user 0,17s system 151% cpu 0,196 total
  └────
-- 
Denis

---

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 18:40:21 +0200

Le 10/10/2022 à 15:31, Vincent Gay a écrit :
>   * \textMark \markup 4x ça passe
>   * \textMark "4x" ça passe
>   * \textMark 4x ça coince
>
>
> erreur fatale : erreur sur les fichiers 
> "/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.ly"
>

Ça, ça ne m'étonne pas, étant donné que tu peux écrire des choses comme

\scaleDurations 4 c

De là, il n'y a qu'un pas vers

\scaleDurations 4c

qui est aussi valide, car LilyPond n'est généralement pas sensible aux
espaces, et enfin

\scaleDurations 4x

où le « x » pourrait très bien être un nom de note dans un certain
\language.

On peut toujours imaginer accepter plus de choses dans la syntaxe, mais
il faut bien tracer une limite à un moment donné. Actuellement, la limite
est fixée sur le principe que les nombres et les caractères alphabétiques
sont dans des entités séparées, sauf à les mettre entre guillemets (ou dans
le mode \markup qui est quelque chose de complètement à part).

Cordialement,
Jean

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 19:06:15 +0200

Le 10/10/2022 à 18:36, Denis Bitouzé a écrit :

Hello Denis, je vais regarder ça

Ce qui pourrait aussi me faire gagner beaucoup de temps serait de savoir utiliser sed avec des expressions contenant des \

principalement quelque chose comme ça

sed -i "s/\polyMark #'rde/\tweak direction #DOWN \textEndMark/g" *.ly

Je ne sais pas comment échapper l'antislash. De plus comme tu le vois il y a aussi un quote dans l'expression à remplacer.

Si quelqu'un a une solution je l'en remercie d'avance

---

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 19:19:10 +0200

Le 10/10/2022 à 19:06, Vincent Gay a écrit :
> Ce qui pourrait aussi me faire gagner beaucoup de temps serait de 
> savoir utiliser sed avec des expressions contenant des \
>
> Je ne sais pas comment échapper l'antislash. De plus comme tu le vois 
> il y a aussi un quote dans l'expression à remplacer.
>

C'est une chose que j'ai mis un certain temps à comprendre.
Il faut mettre quatre antislashs d'affilée, car l'antislash
que tu recherches doit être échappé dans l'expression régulière,
donc en mettant deux antislashs, et chaque antislash
dans l'expression régulière doit être doublé pour Bash, ce
qui fait quatre au total. Par contre, en utilisant
des apostrophes ' au lieu des guillemets pour délimiter
la chaîne dans le script Bash, il n'y a plus besoin que
de deux antislashs.

Et pour le ' lui-même, dans une chaîne avec des " , pas
besoin de l'échapper, et sinon, avec des ' comme délimiteurs,
la syntaxe est assez bizarre :

sed 's/\\polyMark #'\''rde/\\tweak direction #DOWN \\textEndMark/g' *.ly

Au fait, avant de faire ça, j'espère que tu as une sauvegarde.
sed est magique, mais on a vite fait de se planter. (Je parle
d'expérience.)

Cordialement,
Jean

---

From: Vincent Gay <[email-masked]>
Date: Mon, 10 Oct 2022 21:56:22 +0200

> sed 's/\\polyMark #'\''rde/\\tweak direction #DOWN \\textEndMark/g' *.ly 
pffff... C'est magique. Ça m'a fait gagner 3 ou4 heures de boulot. Après 
je devrai vérifier le résultat page par page mais de toutes manières 
j'aurai du le faire. A ce jour le recueil fait 306 pages, à l'arrivée il 
en fera 400 ou plus. Vive sed, vive grep, et merci Jean.

---

From: Jean Abou Samra <[email-masked]>
Date: Mon, 10 Oct 2022 23:08:13 +0200

>    │ 0,13s user 0,17s system 151% cpu 0,196 total

Merci pour le partage, Denis, je ne connaissais pas ripgrep, qui m'a 
l'air très pratique, notamment le fait qu'il exclue par défaut les 
fichiers binaires.

Cordialement,
Jean

---

From: Denis Bitouzé <[email-masked]>
Date: Tue, 11 Oct 2022 09:23:45 +0200

Le 10/10/22 à 23h08, Jean Abou Samra a écrit :

> Merci pour le partage, Denis,

Je t'en prie.

> je ne connaissais pas ripgrep, qui m'a l'air très pratique, notamment
> le fait qu'il exclue par défaut les fichiers binaires.

N'exclue-t-il pas plutôt les fichiers listés dans ton `.gitignore` (et
donc les fichiers binaires) ?

Cordialement.
-- 
Denis