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

[Keith OHara]

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.

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 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".