Keith OHara <k-ohara5...@oco.net> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
