lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64-bit Mac build of 2.20 is now available!


From: David Kastrup
Subject: Re: 64-bit Mac build of 2.20 is now available!
Date: Wed, 18 Mar 2020 13:37:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Davide Liessi <address@hidden> writes:

> Il giorno mer 18 mar 2020 alle ore 13:07 David Kastrup <address@hidden> ha 
> scritto:
>> It doesn't make sense to have convert-ly produce non-working code for
>> version 2.19.40 .  And convert-ly cannot promise to fix code that never
>> worked due to its combination of version statement and old syntax.
>>
>> It isn't guaranteed that you can run convert-ly multiple times for the
>> same version range without producing invalid code.
>
> Would it make sense to have the rule twice, once for the correct
> version and once for post-2.20.0?
> That would produce working code for 2.19.40, while also taking care of
> files that were diligently converted with convert-ly up to 2.20.0 (the
> invalid code in those files is not the user's error but convert-ly's).

Frankly, if you don't keep the originals when producing non-working
code, you could still reapply with the given version range.

And I don't really see the point in providing extra rules for converting
code that never could possibly have worked due to the combination of old
syntax with new \version statement.

That's sort of a bottomless pit.

> Of course provided that the applying the rule twice doesn't ruin the
> code.

At any rate, this is somewhat academical without having a rule for which
we are not certain that applying it once may ruin the code.  That was
part of the justification for not keeping the previously used rule
permanently.  And if we have such dangerous conversions, then jumping
from applying them not at all to applying them several times seems like
adding nuisance (namely people having to manually undo the effects
several times in a row).

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]