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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
