lilypond-devel
[Top][All Lists]
Advanced

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

Re: Create \temporary for doing overrides without pop-first set (issue 6


From: tdanielsmusic
Subject: Re: Create \temporary for doing overrides without pop-first set (issue 6687044)
Date: Mon, 15 Oct 2012 14:46:50 +0000

On 2012/10/15 14:21:08, dak wrote:
On 2012/10/15 14:03:07, janek wrote:
> Hmm.  I've looked at available context properties, and in my opinion
> it could be useful to be able to perform "temporary \sets" on some
of
> them:
>
> associatedVoice
> beamExceptions
> clefOctavation
> crescendoSpanner
> crescendoText
> fontSize
> instrumentName
> instrumentTransposition
> ottavation

Where would be the point to return to a previous ottavation rather
than just setting the desired one?

> PedalSustainStyle
> tupletSpannerDuration

Well, I did not claim that there was _no_ conceivable context property
where a temporary replacement would make sense and/or that we would
never want to implement a stack here.  The question was about the
_default_ behavior, and enough things are _tracked_ in their
_progress_ in context properties that a default stack behavior does
not make sense.

This is where our opinions differ.  I and others believe a default
stack behaviour does make sense.  For most uses there is no
difference between \override followed by \revert for both
behaviours of \override.  It only differs when there are two
or more consecutive \overrides for the same property, and in
that case we will usually want the stack behaviour.  In the
few cases where we really want to clear the stack we suggest
implementing \clear.

I have no idea what you are trying to argue here: of course, if
context and grob properties are supposed to be unified, _both_ will
_have_ a stack implementation if temporary changes in grob properties
are desired.

Exactly.  So let's prepare the way for that now.  What we don't
want is to implement the stack behaviour by a quite separate
command which makes the interface more complicated and unintuitive
and which will be discarded later.

But that does not mean that the default mode of setting a property
should be pushing.

Why not?  What harm will it do?



http://codereview.appspot.com/6687044/



reply via email to

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