lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Naming _another_ lacking puzzle piece


From: David Kastrup
Subject: Re: Naming _another_ lacking puzzle piece
Date: Sun, 14 Oct 2012 10:21:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> Joe Neeman wrote Sunday, October 14, 2012 12:14 AM
>>
>> On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup <address@hidden> wrote:
>> 
>>> \override  overwrites the last definition
>>> \revert  throws it away/reestablishes the previous if not overwritten.
>> 
>> In other words, we have a "pop-push" and a "pop". In the context of
>> Reinhold's email, you were suggesting (although perhaps not seriously)
>> adding a "push". Now, I'm happy to have "push" and "pop," but I think
>> "pop-push" is a bad interface for a stack. The reason that we have gotten
>> away with it for so long is because our interface ensures that the stack is
>> almost always empty anyway (since the only way to "push" is with \once, and
>> that always pops immediately). Once we start talking about composability,
>> the deficiencies of pop-push become clear.
>> 
>> So my proposed set of orthogonal commands would be push and pop (again,
>> with more intuitive names). I also suggest adding clear for convenience.
>> Everything else would be syntactic sugar on push and pop.
>
> I would be happier with this change.  Why not just change the action
> of \override to be push alone?  As its current implementation pretty
> well ensures all the stacks are empty, changing its action to be push
> rather than pop+push would have a limited effect on existing scores,
> wouldn't it?

Exactly _because_ the current implementation pretty well ensures that
all the stacks are empty or close to empty, changing its action to _not_
ensure empty stacks would have a _large_ effect on existing scores.

> I think the point is that \undo will never be ostensibly be written with a
> following \override but rather as \undo \voiceOne.  Its action then would
> be to pop all the \overrides within \voiceOne, returning the state to
> \voiceThree, \oneVoice, or whatever it was before \voiceOne was
> called.
>
> Even so, if the \undo\override did not exactly match the top of the stack 
> it should throw a warning.

The warning could only be thrown at the time the music is actually
iterated, not at the time the \undo is encountered.  That would mean
that \undo\override would have to write significantly different data,
presumably creating music types of its own.  The warning would be
generated at an unexpected time of interpretation.  I don't really think
this is worth the trouble.

With issue 2898
<URL:http://code.google.com/p/lilypond/issues/detail?id=2898>, \undo
gets the feature of a _static_ analysis of what it is supposed to be
reverting, warning at the time of _call_ when it is clear that it cannot
provide something exhaustively countering the property changing effects
of the given command.  This ensures that \undo provides a command that
is fully _suitable_ to be used for countering the given command, and
consistent for that.  Policing the user about not using the command for
anything else would be rather complex to do, and we don't do this kind
of thing elsewhere, like enforcing that \oneVoice may only be used after
\voiceOne or similar.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]