Joe Neeman <
address@hidden> writes:
> On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup <
address@hidden> 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.
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