On 2012/10/15 14:03:07, janek wrote:
On Mon, Oct 15, 2012 at 2:51 PM, <mailto:d...@gnu.org> wrote:
> Let's assume that we "unify" the interface to context and grob > properties. The _default_ operation on a context property will > _always_ be overwrite rather than push, since context properties
track
> the change of things like the current clef, the current key
signature,
> the current whatever. There is no point in keeping a stack for that > by default, and it would be seriously confusing.
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. 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. But that does not mean that the default mode of setting a property should be pushing.
[talk] also, i'd find it nice if it was possible to write \set Staff.color = #red and have LilyPond override #'color property for all grobs belonging to that Staff. Currently doing this requires a music function, so it's out of reach for beginners. If we ever decided to do some "inheritance" of this sort, it would make even more sense to be able to set context properties temporarily. [/talk]
This is not really related to implementing \temporary. It is more related to <URL:http://code.google.com/p/lilypond/issues/detail?id=2832#c3>. http://codereview.appspot.com/6687044/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel