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

[Janek Warchoł]

On Mon, Oct 15, 2012 at 2:51 PM,  <address@hidden> 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