[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: convert.ly errors
From: |
David Kastrup |
Subject: |
Re: convert.ly errors |
Date: |
Thu, 15 Sep 2022 15:38:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Jean Abou Samra <jean@abou-samra.fr> writes:
> Le 14/09/2022 à 19:47, Jean Louis Thiry a écrit :
>> Hello everyone,
>>
>> When using convert.ly <http://convert.ly> (\version “2.23.12”)
>> everything is fine as I do not work on complex scores.
>> But if I compile a 2.19.81 file, for example, converted into 2.23.12
>> everything goes well except for a few errors (always the same) which
>> seem to have been overlooked by convert-ly during the conversion.
>> In the case of my old files which compile well with 2.18.2 or 2.19.81,
>> \override ChordName #'font-series = #’bold
>
> Well, the new syntax has been around for a long time (2012).
> convert-ly did have a conversion rule, but in the version where
> the change was done, not in the version where the old syntax was
> made to actively emit a deprecation warning. It will change
> your override syntax if you run it as
>
> convert-ly --from=2.17.5 --to=2.17.6 ...
>
> David, do you think it would be reasonable to put the same
> convert-ly rule again for 2.23.11?
If I remember correctly, the rule was somewhat icky. Also I think the
rule was (re-)added on a more permanent basis to convert-ly quite after
the actual conversion.
Given how long it took to put in the deprecation warning and how long
older code may have get dragged along, there might be a point in adding
the conversion again in the corresponding version where the warning got
added. However, one should check how conservative the rule is before
adding it again: we don't want accidents to happen to working code.
--
David Kastrup