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". _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
