Joe Neeman <joenee...@gmail.com> writes: > On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup <d...@gnu.org> wrote: > > > > > No. I am just pissed at the people clamoring for more ignorance, > more > > bugs, and less control. > > If you are referring to Werner's and Reinhold's comments, I think you > may not be reading them as the authors intended. In particular, I > believe that Reinhold was merely objecting to the names "push" and > "pop" as being opaque to non-programmers,
To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more ^^^^^ into a programming language and away from being a description of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. > while Werner was complaining that the plethora of new > context-manipulation functions have become confusing. That makes it sound like it would be a chaotic bunch. And what do we have? \override overwrites the last definition \revert throws it away/reestablishes the previous if not overwritten. Then we have modifiers for possibly multiple combined overrides, as those are for example available in large numbers in property-init.ly and we want to be able to use them for as many things as possible without having to retype them with modifications. \once \override non-destructively masks the definition for one time step, then restores \temporary \override non-destructively masks the last definition \undo \override drops like corresponding \reverts would A \tweak goes through a music object rather than through context properties, so we get \single \override (again an \override prefix) converts into one or more tweaks All those are separate tools, apply in the same manner to one or multiple overrides, to get a clear effect derived from the original \override-based command, and complementing each other in functionality. People shout "I want fewer", but they are a set. It's like saying you want a smaller set of spanners, so you leave out every second one. But that means that you won't be able to do a random subset of required tasks because the spanners are a full set. You can't just randomly leave out some and expect to be able to still do every job. > I interpret his comments as a request for orthogonalization rather > than a complaint about the options that the new commands > introduce. What's not orthogonal here? _Every_ modifier works on \overrides (granted, \undo will also work on \set but just because it does not make sense not to include this as well). \once allows a one-step temporary replacement, \temporary and \undo allow the start and stop of a temporary replacement to be separately specified. \single converts into a different grob modifier mechanism. No, the complaint was clear, from several parties: 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. [...] 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). [...] Plus \once and now \temporary. I agree this menagerie is going to be far more confusing to users than the occasional unexpected result after calling \crossStaff or \harmonicByFret - which no one has ever noticed. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. > Now, it's true that the comments may not have been entirely > constructive as they didn't propose alternatives, but I also don't > think anyone claimed that your proposal is worse than the status quo. The last comment above states "we're going too far in this direction now", calls the commands a "confusing menagerie" and states that nobody noticed the kind of bugs one can fix with that anyway. "quite confused enough" clearly strongly speaks against providing any more commands, preferring to stay with problems instead. > For what it's worth, I think push, pop and clear (perhaps with more > intuitive-to-non-programmer names) makes a nicer stack interface than > push, pop-push and pop. What is "clear" supposed to be? > I also think that "undo" should be rethought in light of this recent > discussion. In particular, this discussion has made me realize that > "undo" doesn't just reverse the effect of an override, since after > \override Something #'color = #green \override Something #'color = > #red \undo\override Something #'color = #red, then the color is not > back to green as one might think. An \override overwrites the last value if any, and it is gone. That's not a problem of \undo. > What if we gave the users a "push, pop and clear" interface and we > made overrides use "push" and \oneVoice use "clear"? This solves the > \voiceOne\voiceTwo\oneVoice > problem No. Quite a few commands intended to be used "at bottom" have a combination of overrides and reverts. Having the reverts remove everything to bottom of stack and the overrides not is not going to make things more predictable. > \override Something #'color = #green > \override Something #'color = #red > \undo\override Something #'color = #green > go back to the pre-green color. Not useful. This is primarily of interest when the outer and the middle part are provided from different sources and don't know what the respective other is, and if the middle part happened to be \override Something #'color = #green for whatever reason, suddenly the scope of the \undo would flip. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel