"Trevor Daniels" <[email protected]> writes: > David Kastrup wrote Sunday, October 14, 2012 9:21 AM > > >> "Trevor Daniels" <[email protected]> writes: >> >>> I would be happier with this change. Why not just change the action >>> of \override to be push alone? As its current implementation pretty >>> well ensures all the stacks are empty, changing its action to be >>> push rather than pop+push would have a limited effect on existing >>> scores, wouldn't it? >> >> Exactly _because_ the current implementation pretty well ensures that >> all the stacks are empty or close to empty, changing its action to >> _not_ ensure empty stacks would have a _large_ effect on existing >> scores. > > I'm not so sure.
Well, I did the detective work of tracking down _when_ the change was made (October 2005 by Han-Wen). So there is already a history of LilyPond with this decision made differently. The decision, however little record of its motivation I have been able to dig up beyond the commit itself, was not an accident. There was clearly code added for that exact purpose. "Who does not know history is bound to repeat its mistakes." It would appear that we _have_ a history, we don't know it any more, and I suspect we are bound to repeat its mistakes. So I am trying to reverse-engineer the reasons for that decision, and what I arrive at appears plausible to me. And the current discussion appears to match my conclusion, this conclusion being "for typical use of these user-level commands, stack-like semantics appear to cause surprises that most normal(TM) users are not well-equipped to deal with." The current programming layer and naming conventions for Scheme programmers are a misleading piece of incoherence, but at the LilyPond user level, a reasonably straightforward non-stack behavior is the default. A stack depth greater than 1 can only be caused by non-user-level code, and that non-user-level should be written in a fashion cleaning up after itself. What \temporary does is provide a LilyPond interface for writing such non-user-level code cleanly. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
