lilypond-devel
[Top][All Lists]
Advanced

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

\temporary \override (was: stepping down as project manager)


From: David Kastrup
Subject: \temporary \override (was: stepping down as project manager)
Date: Sun, 14 Oct 2012 09:36:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

It looks like I have managed to somehow hijack a thread which was
_definitely_ about something else.  This is inappropriate and I
apologize.  I hope the change of subject will help disentangling this.

> The actual problem is that \override currently CLEARS (i.e. reverts)
> the current value before setting the new one, so that the old value is
> not stored anywhere any more, and a \revert thus reverts to the
> default value.
>
> As an example, let's look at the following code. What color would you
> expect the final "b" to have? red? (because the \revert clears the
> previous override to blue, right?)
>
> \version "2.16.0"
>
> \relative c' {
>   c4
>   \override NoteHead #'color = #red
>   f
>   \override NoteHead #'color = #blue
>   g
>   \revert NoteHead #'color
>   b
> }

I would think that you are already carrying a "stack" expectation into
this example.  The original change to pop-push (for which I can't find
rationale or discussion) presumably was because users were unprepared
for dealing with the consequences of a default stack-like behavior and
were rather expecting to have

\override
\override
\override
\override
\revert

be the "neutral" operation.

> In reality, the \revert does not revert the override, but completely
> clear the value to the black default. Currently, there is no way to
> temporarily change a property and then change it back to its previous
> value (except for \once\override, which only works for one timestep).
>
> In fact, \override and \revert are currently misnamed, they work more
> like \set and \unset.

The user-level difference between \set/\unset and \override/\revert is
not that they have different behavior, but that the first pair is for
manipulating direct properties of a context, and the second pair is for
manipulating the grob property defaults of a context (grob properties
have a different internal representation for efficiency reasons, though
they are not conceptually all that different from nested context
properties).

-- 
David Kastrup




reply via email to

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