On Mon, Oct 15, 2012 at 2:51 PM, <d...@gnu.org> wrote: > Reviewers: janek, Trevor Daniels, > > Message: > > On 2012/10/15 10:45:02, Trevor Daniels wrote: >> >> I'm not sure this is the right way to go. >> Here's my reasoning: > > >> a) Unifying the interface to context and grob properties >> seems to be a desirable long-term goal; at least several >> people have spoken in favour of it. But we do not yet >> have a proposal for doing this. In particular we do not >> have agreement about desirable syntax and semantics for >> modifying properties, although several suggestions have >> been made. > > > 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 PedalSustainStyle tupletSpannerDuration [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] >> b) The present semantics of \override are clearly deficient, >> as evidenced by the need for this patch, in that a proper >> stack of properties is required to avoid called functions >> changing the settings made by the caller. > > That is like saying my right leg is clearly deficient, as evidenced by > the need for the left leg if I want to walk somewhere. > > The solution is to use it in combination with a left leg, not > amputating it and then devising a new interface for walking. lol! :D While that was fun, i'm pretty sure that wasn't what Trevor had in mind :) cheers, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel