différents caractères "fin de ligne"

Bonjour et meilleurs vœux à toute la liste,
Je voudrais signaler un comportement très curieux qui est peut être
provoqué par un caractère bizarre que j’ai attrapé, je ne sais comment.
Je travaille avec un MAC sous OSX version 10.4.11 avec la version 2.13.34
de lilypond.
Je travaille le plus simplement du monde (je suis toujours très paresseux
malgré mes 78 ans) : j’ai téléchargé la version de lilypond et celle de la
documentation que je consulte très fréquemment dans sa version .pdf
J’avais transformé un programme obtenu de Mutopia (merci à ce site et à
Gérard Gréco qui a transféré le choral BWV21 sous lilypond).
J’en ai fait facilement un quatuor, car les différentes voix existaient
déjà dans la version de Gérard Gréco. J’ai fait ensuite quelques
transformations et la compilation fonctionnait correctement.
Puis j’ai voulu faire quelques repères dans le fichier musique, et j’ai
ajouté des numéros de mesure pour me permettre de m’y reconnaître à
l’avenir. j’ai écrit à la fin de quelques lignes le numéro de mesure à la
suite du signe ‘%’.
La compilation plantait méchamment : en pièces jointes les deux fichiers
.ly (quatuor_badRTCR.ly et musique_badRTCR.ly) ainsi que la copie du
fichier de compilation que j’ai recopié dans un fichier .ly
(compil_badRTCR.ly)
Si l’on supprime les numéros de ligne (précédés du %), la compilation est
parfaite.
Après quelques essais, j’ai constaté que certaines lignes n’étaient pas
terminées par un caractère de fin de ligne normal mais par un autre
caractère qui provoque le changement de ligne dans l’éditeur. J’ai supposé
que ce caractère n’était pas interprété comme une fin de ligne par le
compilateur de lilypond, de sorte que la ligne suivante devait être aussi
considérée comme commentée, ce qui expliquerait bien sûr la catastrophe.
Je ne sais pas comment j’ai attrapé ce caractère bizarre qui doit exister
dans pas mal de mes fichiers .ly, mais qui ne cause de problème que si un
% se trouve placé avant lui.
Pour vérifier cette hypothèse, j’ai modifié ma méthode de numérotation de
mesure : au lieu d’écrire %nn en fin de ligne j’écris %{nn%}. Tout rentre
alors dans l’ordre (cf pièces jointes quatuor_modRTCR.ly
musique_modRTCR.ly et compil_modRTCR.ly).
La méthode de commentaire %{...%} n’a en effet pas besoin d’un caractère
“fin de ligne” pour faire cesser l’action commentaire.
J’ai vérifié que le caractère bizarre ne provenait pas du fichier
téléchargé à partir de Mutopia. Peut-être provient-il de ma manière de
copier les renseignements extraits de la documentation .pdf : je fais
souvent un copié-collé à partir du .pdf lui-même.
Excusez ce long discours, mais je me suis dit que d’autres pourraient
avoir les mêmes désagréments que moi.

quatuor_badRTCR.ly (2.04 KB)

musique_badRTCR.ly (7.68 KB)

suite du précédent message : les autres pièces annoncées n'ont pas été
envoyées

compil_badRTCR.ly (2.5 KB)

quatuor_godRTCR.ly (2.04 KB)

musique_godRTCR.ly (7.68 KB)

quatuor_modRTCR.ly (2.04 KB)

suite du précédent message : les autres pièces annoncées n'ont pas été
envoyées

musique_modRTCR.ly (7.8 KB)

compil_modRTCR.ly (450 Bytes)

Tout compile sans problème ici (2.13.46, Linux, éditeur Frescobaldi) :
god, bad et mod (directement téléchargés et compilés).
Mais peut-être que le simple fait d'envoyer les fichiers par e-mail
"corrige" les caractères de fin de ligne. Il me semble qu'il y a
plusieurs normes pour EOL (UNIX et autres) mais je n'ai jamais eu de
problème avec des fichiers .ly .

Tu utilises quel éditeur ?

Sinon bien vérifié que l'encodage est bien UTF-8.

Cordialement,
Xavier

PS : Manquait "musique_modRTCR.ly". :smiley:

···

2011/1/20 <****@****>:

Bonjour et meilleurs vœux à toute la liste,

[...]

Après quelques essais, j’ai constaté que certaines lignes n’étaient pas
terminées par un caractère de fin de ligne normal mais par un autre
caractère qui provoque le changement de ligne dans l’éditeur. J’ai supposé
que ce caractère n’était pas interprété comme une fin de ligne par le
compilateur de lilypond, de sorte que la ligne suivante devait être aussi
considérée comme commentée, ce qui expliquerait bien sûr la catastrophe.

--
Xavier Scheuer <****@****>

Bonjour et meilleurs vœux à toute la liste,

[...]

Après quelques essais, j’ai constaté que certaines lignes
n’étaient pas
terminées par un caractère de fin de ligne normal mais par un autre
caractère qui provoque le changement de ligne dans l’éditeur. J’ai
supposé
que ce caractère n’était pas interprété comme une fin de ligne par
le
compilateur de lilypond, de sorte que la ligne suivante devait être
aussi
considérée comme commentée, ce qui expliquerait bien sûr la
catastrophe.

Tout compile sans problème ici (2.13.46, Linux, éditeur Frescobaldi) :
god, bad et mod (directement téléchargés et compilés).

C'est donc un problème spécifique au compilateur MAC.

Mais peut-être que le simple fait d'envoyer les fichiers par e-mail
"corrige" les caractères de fin de ligne. Il me semble qu'il y a

Non, ce n'est pas le cas, car je viens de récupérer les fichiers à partir
de LilyPond French Users
et j'ai toujours la faute si je compile ces fichiers récupérés.

plusieurs normes pour EOL (UNIX et autres) mais je n'ai jamais eu de
problème avec des fichiers .ly .

Tu utilises quel éditeur ?

je ne sais pas : celui qui m'est donné quand le chargement d'un .ly charge
le compilateur lilypond.
je suis alors dans environnement qui me convenait toujours jusqu'à
maintenant.
J'ai par contre vérifié qu'il y avait bien 2 caractères différents qui
provoquaient la fin de ligne dans l'éditeur : en recherchant à l'aide du
find le vrai caractère de fin de ligne, je trouve que certaines lignes ne
l'ont pas.
Si maintenant je saisis ce caractère bizarre (à l'aide de la commande
CtrlE du find en me plaçant justement sur les fins de ligne qui n'ont pas
été vues par la recherche précédente) et que je le remplace par le vrai
caractère fin de ligne (à l'aide de Replace All) , je compile sans
problème le fichier ainsi corrigé.

Sinon bien vérifié que l'encodage est bien UTF-8.

Cordialement,
Xavier

PS : Manquait "musique_modRTCR.ly". :smiley:

j'ai du m'y reprendre à 3 fois car j'envoyais par mégarde le mail avant
d'avoir récupéré les fichiers.

···

2011/1/20 <****@****>:

--
Xavier Scheuer <****@****>