Werner LEMBERG <[email protected]> writes: >> [...] if I write >> >> \omit Accidental >> cis dis cis dis >> \pop\omit Accidental >> >> this looks ugly and not properly matched, and it _is_ not properly >> matched. If there was a non-standard stencil set in that context >> previously, it is gone. >> >> So maybe \pop (complemented by \push) is indeed a better name than >> \undo. > > But `push' means `to put something on the stack'. Having > > \omit Accidental > > however, does exactly the opposite, this is, it *removes* something
Uh no, it doesn't. It pushed a ##f property to the stack of Accidental.stencil. > (well, it pushes the `omit' property, so to say, but this can become > very irritating if it gets more complicated). For this particular > reason I prefer \undo for the example you've given above. > > I get the feeling that we have to completely reconsider how \set, > \revert, and friends are named and used. Your clean-ups and > reorganization of the syntax reveal more and more inconsistencies, and > my head starts aching if I think of \once, \undo, and so on. Well, at least the \grob/\on/\tweakGrob things are tabled again. Changing \override Accidental color = #red to \override Accidental.color = #red and related changes make _those_ abominations redundant. > Maybe it makes sense to map the corresponding Scheme functions anew to > `simpler' lilypond commands which do less but in a more consistent > manner. \once \push \pop \tweak \single _are_ rather minimal and do a single job each. \once changes overriding music into a push/pop pair, \push into push sequences, \pop into pop sequences, \tweak directly manipulates a grob, \single converts overriding music into a \tweak. The rest is tabled after discussion. \omit can be either tweak or override, depending on its last argument, same with \hide, same with \footnote. Just because this is a long discussion covering a lot of ground (and throwing stuff out again) does not mean that the _results_ are bad. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
