Re: How to procede with \override/\revert business

[David Kastrup]

Keith OHara <address@hidden> writes:

> David Kastrup <dak <at> gnu.org> writes:
>
>> Keith OHara <k-ohara5a5a <at> oco.net> writes:
>>
>> > I timed LilyPond setting the percussion parts of a symphony, 
>
>> Huh, I'd not have expected a net slowdown.  Were you using the version
>> _after_ running convert-ly, or are we talking about "compatibility mode"
>> where the #' syntax is still being employed everywhere?
>
> I did convert-ly the input files first.  For the comparison timing, though,
> I went back further than really necessary, to essentially version 2.17.3,
> so maybe other changes affected the timing.  The point was that any change
> is insignificant -- and hard to measure because even for a four-movement
> symphony the percussion parts require only 25 seconds, so the difference
> is 1/4 second.
>
>
>> > Unifying \override and \set seems harder now. 
>
>> I don't think that this is actually making a difference with regard to
>> "unification".  Grobs are conceptually just context properties (and
>> would be completely so after unification), and there is no situation
>> where both context name as well as grob name would be optional.
>> 
>
> Well, the parser doesn't know the possible context names, so I suppose
> you mean that either a Grob or context-property name must be present.

After "unification", it would not be an either/or since both would be
the same.

> Just to be concrete, we can now write
>   \set Lyrics.fontSize = #3
>   \override LyricText.font-size = #3
>
> Suppose \set and \override merge into one operation called \let 
> (out of nostalgia for BASIC, maybe) and that a user is forgetful or 
> confused and types
>   
>   \let Lyric.fontsize = #3

The fine distinctions in namings are increasingly harder to distinguish
from sadism.  At least now that there is no compelling technical reason
prohibiting the use of dashes in some circumstances.

> The parser could try to find 'Lyric' in the structure defined in
> "define-grobs.scm", and failing that look for 'fontsize' in the
> structure defined in "define-context-properties.scm".
>
> In this case since both searches fail I suppose the parser should warn
> "cannot recognize the name of any Grob or context-property" but
> generate a propertySet on the chance that later input defines a
> "Lyric" context and a Scheme engraver that reads a property
> "fontsize".

I don't think that we should plan for interfaces where you can
tentatively use properties before defining them.  There is just too much
that can go wrong with that.

-- 
David Kastrup