Re: Context.Grob considered as symbol list

[David Kastrup]

David Kastrup <address@hidden> writes:

> Werner LEMBERG <address@hidden> writes:
>
>>>> 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.?
>>>
>>> Technically impossible.  At the time an \override is parsed, the
>>> valid set of contexts has not been established.
>>
>> OK.  And the interpretation of the just parsed data (this is, checking
>> the validity of contexts, properties, etc.) can't be delayed, right?
>
> Context validity can't be checked at that point of time.  The system
> of available properties, however, is more or less considered static,
> so the basic consistency checks for overriding existing/non-existing
> properties are being done while parsing.  However, I consider it a bad
> idea to use "insider" knowledge for parsing an override (meaning skip
> ahead until finding a word declared as a grob property and split the
> input backwards from there) since it means that understanding the
> input requires knowing _all_ prospective properties, whether it is a
> human, a LilyPond importer, a syntax highlighter, a cross referencing
> tool or LilyPond itself that is trying to interpret the input.

But then most of those don't need to _understand_ the input really.  And
it turns out that _all_ decisions, whether we are talking tweak or
override, can be made on the criterion "is the first element in the list
a grob name?", the decision that currently _can_ be made statically.  Of
course, the "call interface" of \override/\revert currently expects
_two_ symbol chains.  Conflating these chains (making \tweak and
\override compatible again) is not really a backward compatibility
problem for \override since its $#!? syntax demands conflating symbol
lists before the '=' signs anyway.  \revert, however, is a different
matter.  It currently needs exactly two symbol chains as argument.  To
accept only one, it would need to first accept one symbol chain, check
it, and then _only_ in case that this symbol chain _ends_ in a grob
name, parse another one.

Very unpretty.  But yes, it would likely get a load of users off our
necks.

-- 
David Kastrup