Re: Context.Grob considered as symbol list

[Werner LEMBERG]

>>   \tweak Accidental.color #red cis
>>
>> vs.
>>
>>   \override Voice.Accidental color #red
>
> \tweak gets one symbol list, \override gets two symbol lists.  The
> symbol list for \tweak may optionally start with a grob name, the
> first symbol list for \override may optionally start with a context
> name.  [...]
>
> Yes, the difference in visuals for quite similar commands is a bit
> of a nuisance, but it is not the only difference.  You forgot the
> equals sign in the \override command...

I've omitted it intentionally, since it isn't relevant to the argument
I want to hold.  For both commands, I see a hierarchy, and for me *as
a user* the syntax difference looks artificial.  Instead of having an
optional argument 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 (where LilyPond complains if a hierarchy element is
missing or inappropriate).  I'm aware of the potential namespace
clashes, so no need to reiterate this :-)

On the other hand: Wouldn't it be possible to make LilyPond simply
walk over all possible combinations to find out whether, say,

  foo.bar

is a context followed by a property, or a property followed by a
sub-property, etc.?  Is this too expensive?  Or is this technically
impossible?  AFAIK, compilers do something similar, warning about
ambiguities.


    Werner