Re: Context.Grob considered as symbol list

[David Kastrup]

Keith OHara <address@hidden> writes:

> Werner LEMBERG <wl <at> gnu.org> writes:
>
>> Instead of having an optional argument 
>
> Remember that David's previous approach used no optional arguments,
> the optional components were attached with dots to the core arguments
>   
>   \override [Context.]Grob property[.subproperty] = #value
>   \tweak [Grob.]property.[subproperty] value c2
>
>> I would prefer that both commands simply accept such
>> a hierarchy, making e.g.
>> 
>>   \override color ...
>>   \override Accidental.color ...
>>   \override Voice.Accidental.color ...
>> 
>> and
>> 
>>   \tweak color ...
>>   \tweak Accidental.color ...
>>   \tweak Voice.Accidental.color ...
>> 
>> valid syntax

That's what is accepted in the current version of the patch.  Of course,
except for \tweak Voice.Accidental.color which makes _absolutely_ no
sense whatsoever since tweaks are not associated with contexts.  And
actually, it _will_ get accepted but will probably complain later that
the tweaked grob does not have a grob property called "Voice".

> Remember that by far the most common cases use no optional components,
> thus no dots in the old syntax.  Also remember that 
>  \override color = #blue
> will not do anything useful even if it is valid syntax. (David's latest 
> patch prints a reasonable message for the error above, before
> crashing.)

It just does the following non-fatal error in the current version
(updated at origin/dev/syntax):

xxx.ly:1:12: error: bad grob property path
{ \override 
            color = #blue }

That's good enough.

> I would prefer to keep David's previous syntax in documentation, even if
> we accept the fully-dotted form, because the space helps me find my way
> when copying new forms from the manuals.
>
>   \override Ceol.Clochan dath.mion = #glas
>
> I forget a lot, but am reminded seeing the above that \override always 
> takes a grob (sometimes with context to its left) and the property 
> (rarely with sub-properties to its right).

On the other hand, things like \overrideProperty can only have one
interface or the other, and "put a single dotted symbol list here to
specify the path" with no alternative readings is dead simple and
straightforward.  And starting with version 2.19, or at the latest 2.21,
I would want to remove the compatibility mode which is really
complicating things both in the parser as well as conceptually.

-- 
David Kastrup