Re: Change to \rest markup in 2.23

[David Kastrup]

Thomas Morley <thomasmorley65@gmail.com> writes:

> Am Mi., 20. Juli 2022 um 14:29 Uhr schrieb David Kastrup <dak@gnu.org>:
>>
>> David Kastrup <dak@gnu.org> writes:
>>
>> > Jean Abou Samra <jean@abou-samra.fr> writes:
>> >
>> >> Le 20/07/2022 à 05:57, David F. a écrit :
>> >>> In 2.23, the rest markup command changed from taking a string to taking 
>> >>> a duration.
>> >>>
>> >>> \version "2.22"
>> >>> \markup \rest #"4.."
>> >>>
>> >>> \version "2.23"
>> >>> \markup \rest { 4.. }
>> >>>
>> >>> It would be nice if this change were backward compatible, at least
>> >>> for a version or two.
>> >>
>> >>
>> >> LilyPond's general policy is that backwards-incompatible syntax
>> >> changes are OK as long as a convert-ly rule is provided to update
>> >> input files automatically.
>> >>
>> >> Well, in this case there is no convert-ly rule ... I'll fix that soon.
>> >
>> > I was "what?!?!?" about this but then the convert-ly rule I did was for
>> > \note in a quite earlier version.  It's probably reasonably easy to just
>> > copy and adapt that rule.
>>
>> I'll do that.
>
> Hi David,
>
> there was some off-list discussion already.
> Looks I forgot to do some convertrule with
> https://gitlab.com/lilypond/lilypond/-/merge_requests/627
>
> Though, c/p and adjust the rule for note-markup will probably not work.
> At least for me this rule looks broken:
>
> $ cat atest-116.ly
> \version "2.18.0" \markup \note #"4."
>
> $ ../../../lilypond-git/build/out/bin/convert-ly -e atest-116.ly
> convert-ly (GNU LilyPond) 2.23.11
>
> convert-ly: Processing `atest-116.ly'...
> Applying conversion: 2.19.2, 2.19.7, 2.19.11, 2.19.16, 2.19.22,
> 2.19.24, 2.19.28, 2.19.29, 2.19.32, 2.19.39, 2.19.40, 2.19.46,
> 2.19.49, 2.20.0, 2.21.0, 2.21.2, 2.23.1, 2.23.2, 2.23.3, 2.23.4,
> 2.23.5, 2.23.6, 2.23.7, 2.23.8, 2.23.9, 2.23.10, 2.23.11
>
> $ cat atest-116.ly
> \version "2.23.11" \markup \note #"4."
>
> Cheers,
>   Harm
>

The rule was used for converting all the old stuff in the repo, so it
wasn't broken at one point of time.  This would suggest either a Python
update effect or some editing.  Or for some reason this particular input
escapes the pattern match.

I'll try fixing that, too.

-- 
David Kastrup