David Kastrup <[email protected]> writes: > Reinhold Kainhofer <[email protected]> writes: > >> Am Freitag, 5. August 2011, 19:08:43 schrieb David Kastrup: >>> Proposal 1: \override should not start with an internal \revert but >>> rather do just what the user documentation says: push its own version in >>> front of the existing alist of properties, without deleting existing >>> overrides. >> >> That's what I would expect, too. >> Of course, then the list of overrides will grow with every override and >> might >> be quite large for a very long score... > > Hm? Either you want to override once, then the net result on the stack > is none anyway, or you want to override permanently, then their is no > growth, or you switch back and forth, then you'll need to revert in > between. But as things are currently, it is impossible to use \override > for establishing a basic setting in the context: with the first > \override/\revert pair, the basic setting is _gone_. And you can't use > \set for grob properties, either.
Anyway, I think that my given example was flawed in that it likely relied on unintentionally broken behavior. I probably was mistaken about the intended behavior (override likely is intended to do a push without a previous pop), but then given the quality of the user documentation, I have to rely on a combination of actual behavior and my interpretation of the code. It does not exactly help that I currently get throws in critical sections galore, maybe a problem with gcc/binutil/whatever. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
