On Sun, Oct 14, 2012 at 1:26 PM, David Kastrup <d...@gnu.org> wrote:
> Joe Neeman <joenee...@gmail.com> writes:
>
> > On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup <d...@gnu.org> wrote:
> >
> > You are viewing this from the "stack" angle. But that is a complex
> > view already. The actual user view is
> >
> > A.
> > \override sets a context-specific property value
> > \revert removes a context-specific property value
> > This works reliably. If I ever need more complex stuff than that,
> > I can
> > look it up.
> >
> > And to make the "this works reliably" part work, we won't expose
> > any
> > isolated \temporary \override without matching \revert in
> > LilyPond.
> >
> > How do you plan to achieve this? If there are any commands using a
> > \temporary...\revert that spans for more than one timestep, I can
> > always nest them and I can always sneak in \overrides between the
> > \temporary and the \revert, just by putting music in parallel.
>
> "Sneaking" is expected to cause problems, and sneaking in _overrides_ is
> not problematic as they just change the _top_ of the stack, and that
> gets reverted anyway. Only sneaking in _reverts_ destroys the stack
> balance, and that means that some states get reverted _more_ than
> appropriate. However, if the expectation of the user is that they get
> reverted _totally_ when he writes reverts, things end up better than
> expected.
>
[talk] If you want this to be the user's expectation, then perhaps it would
be more appropriate to have \revert clear the stack entirely. Consider
something like this:
\redNotes { ...
\greenNotes { ...
\override NoteHead.color = #purple
...
\revert NoteHead.color
}
...
}
where the functions redNotes and greenNotes use a push. With the current
behaviour, the note colors will go red, green, purple, red, black, so the
\revert neither undoes a single change nor does it return to the default.
If \revert clears the stack, then you'll get red, green, purple, black,
which is not ideal in my opinion, but at least better than the earlier
option. (My preferred behaviour would be red, green, purple, green, red.)
> > People have complained about \push/\pop being intolerably
> > programmer-centric _terminology_, but terminology is cheap. The
> > underlying fear was "people won't understand what push/pop does",
> > and
> > that can't be cured by using prettier names but only by not doing
> > anything hard to understand unless asked for it.
> >
> > I think stacks are easy to understand, even for non-technical users.
> > The reason for avoiding push/pop is just to stop people from thinking
> > "oh, that's programming, it must be hard."
>
> Having to keep a stack properly nested _is_ a nuisance. The fundamental
> complaint about Scheme as the core programming language of LilyPond is
> that you need to keep so many parentheses nested.
>
An override stack is more forgiving than nested parentheses for two
reasons: first, it isn't an error if you have a non-empty stack at the end
of the piece, and second, there would be a command to clear the stack and
reset the default. It is admittedly hard to know for sure without trying
it, but I find it hard to imagine that keeping track of the stack will
cause difficulties.
>
> > LilyPond is _complex_, and sometimes one needs that complexity.
> > But we
> > should try to keep simple things simple, and leave the need to
> > understand complex behavior for when complex things are required.
> >
> > While that's true, I think that a coherent and consistent whole is
> > more important than a slightly simpler beginner interface.
>
> I don't find the user interface, as it is, inconsistent. One rarely
> needs to bother with the full power of a stack (heck, we got along
> 7 years without a hook into push), and the non-pushing default of
> \override reflects that.
>
But now that we are giving a hook into push, I think that the non-pushing
default of override will cause problems.
Cheers,
Joe
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
