Hello, On 14 October 2012 07:39, David Kastrup <[email protected]> wrote: > Reinhold Kainhofer <[email protected]> writes: > >> On 2012-10-13 23:44, David Kastrup wrote: >>> \once creates a one-time-step temporary change, \temporary an >>> unterminated temporary change which can be terminated element-wise with >>> \revert >> >> +1 >> That's a consistent naming scheme, and \temporary is a perfect match >> with \once, so I'm all for that name. \once changes the value for one >> step, \temporary until it is explicitly \revert'ed (und unfortunately >> \override alone permanantly overwrites rather than overrides). > > It is so that \override ... \override ... \override ... \revert gets > back to the initial state (though with a net pop, so you better start > out on an empty stack). Those overrides can come in packages, like > > \voiceOne ... \voiceTwo ... \voiceOne ... \oneVoice > > and many of those packages are designed to be used in a non-stack-like > manner, presumably because some of them contain a mixture of overrides > and reverts and/or Han-Wen had given up on teaching people about popping > everything they pushed. > > If you want the above to return to its original state even in case of a > non-empty stack, it turns out that writing \temporary before the first > \voiceOne will do the trick, but that requires the knowledge that those > commands are organized as a matched set. The safe/blackbox way to do it > would be to \temporary every \voiceXXX command, and afterwards \undo it, > and that presumably was the original design. > > It apparently (as I said, this was done in an only loosely related large > 2005 commit without comments, without mention in the log files and > commit messages and apparently without preceding discussion) was changed > after it turned out that users were not coping well with stacks.
That is probably the most coherent explanation I have had of this whole thread :) thanks. As a normal user I think a \revert should turn off (i.e. I'd expect it go back to default) and was trying to think of a way to say this in an email myself, but then wondered what happened in the case of all those 'functions' in the ly/directory where multiple overrides and reverts would make this complex and give unexpected results. I think users, if explained with good examples, would get the 'pop' and 'push' concept but I also agree that this is too complex for _most_ LP users to have to think about (if not understand). > > The current semantics are basically non-stack, but the stack can be > reanimated temporarily from the Scheme layer. > > This reanimation makes sense from the user layer in some cases as well, > particularly when we are talking about "programming" in LilyPond > (writing reusable parts), something which was considered more of an > oddity/curiosity in 2005 than it is now. Yes :) and I am also guessing that those that use these features are the most vocal on the list precisely because they understand what they are doing when they use these 'fancy-shmancy' gymnastics within their music; (me? I just cut and paste stuff again and give it a new $name, this leads to much less 'thinking' and more importantly for me, admin work when I go back to a piece of work and wonder at my own impressive LilyPond skills that I have now forgotten) oh and means if I really make a mess with an edit it is much easier for me to fix it. Which leads on to: > > So based on the assumption that Han-Wen's stealthy change was due to a > stack having shown itself to be too complex for "normal (TM)" users, it > makes sense to structure the documentation for \temporary/undo in > relation to the basic \override/revert such that the user is comfortable > _not_ being familiar with them while at the same time having access to > the advanced information should he ever need it. It is not a must-learn > item, but a good-to-know-occasionally one. So I don't see any harm in keeping it simple in the Learning Manual but 'getting down and dirty' technically in the NR with an @ref back to the LM. James _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
