Re: convert-ly does not provide a compilable result

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Noeck <address@hidden> writes:
>>
>>> perhaps I am too demanding, but shouldn't this syntax be updated by
>>> convert-ly?
>>>
>>>
>>> \version "2.16.0"
>>>
>>> \paper {
>>>   system-system-spacing #'padding = #7
>>>   nonstaff-nonstaff-spacing #'padding = #8
>>> }
>>>
>>> \markup \null
>>>
>>>
>>> Running convert-ly (version 2.19.50) on it does not change the syntax
>>> (except for the version number) but then running lilypond on it complains:
>>>
>>> Fehler: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' or ','
>>>   system-system-spacing
>>>                         #'padding = #7
>>>
>>>
>>> I would expect convert-ly to update this to
>>>
>>>
>>> \paper {
>>>   system-system-spacing.padding = #7
>>>   nonstaff-nonstaff-spacing.padding = #8
>>> }
>>
>> I was pretty sure of having programmed that.  There is issue 4068 doing
>> such a rule,
>
> <https://sourceforge.net/p/testlilyissues/issues/4068/>
>
>> but also reverting it again.  Presumably I did not think the rule
>> robust enough to be enabled permanently.  But obviously this is a
>> problem we should not just ignore.  Perhaps do a version that will
>> work after a line beginning and/or { ?

That issue states:

    When pushed to staging, another commit reverting the convert-ly rule
    will be added since we don't want to apply somewhat generic patterns
    like those on unknown user-provided code when unchanged code remains
    valid.

But the "when unchanged code remains valid" part is gone: unchanged code
became invalid with
<https://sourceforge.net/p/testlilyissues/issues/4800/>

The discussion for the code review for that patch suggests that I was of
the opinion that such a convert-ly rule was in place after all.

So yes: this needs fixing.

-- 
David Kastrup