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