Janek Warchoł <janek.lilyp...@gmail.com> writes: > On Sat, Oct 13, 2012 at 2:01 AM, David Kastrup <d...@gnu.org> wrote: >> There is a problem with that: in terms of stack operations, \override >> and \revert are not opposing pairs: \override is pop+push (so that >> multiple overrides in a row don't accrue cruft), \revert is pop. So the >> net effect of this sequence is "pop", while it should be neutral. > > This looks strange indeed. > I've skimmed this thread, but haven't found an answer to this > question: would it hurt us really much to have multiple overrides > "accumulate cruft"? I suppose that in real-life situation there won't > be that much cruft accumulated - but i might be completely wrong.
\voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? > In other words, we have \override, \tweak, \set, \revert, \unset, > \undo, \single (and maybe more). It's getting confusing, at least for > me. I'd prefer to decrease the number of such functions, not increase > them (without deleting functionality, of course). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of "Great, finally we get a tool for doing x in a straightforward way", everybody is always hollering "oh no, not another tool. Can't we just live with the deficient state?" Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
