David Kastrup <d...@gnu.org> writes: > Werner LEMBERG <w...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel