Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/5/1 Carl D. Sorensen <address@hidden>:
>
>
>
> On 4/26/09 9:31 AM, "Neil Puttock" <address@hidden> wrote:
>
>> 2009/4/26 Trevor Daniels <address@hidden>:
>>
>>> Just to recap, the advantage of \override over \set is that previously
>>> overridden values can be recovered by \revert because they are
>>> pushed onto a stack, whereas \unset simply restores the original
>>> default value.  Is that right?
>>
>> Yes.
>
> That's not the only advantage.  With /override, I can go down into the alist
> of properties and set an autobeam setting for just one time signature.  With
> /set, I need to set the whole alist.
>
> There are two reasons for this.  First, /set replaces the value, while
> /override conses the value to the front of the alist. Second, there's no way
> to get down into the alist with /set.
>
> I can do:
>  \override AutoBeamPlaceholder #'auto-beam-setting #'(end 3 4) =
>    #`((* . (,(ly:make-moment 1 4)
>            ,(ly:make-moment 2 4)
>            ,(ly:make-moment 3 4))))
>
> But I can't do:
>  \set myNewAutoBeamSetting #'(end 3 4) =
>    #`((* . (,(ly:make-moment 1 4)
>            ,(ly:make-moment 2 4)
>            ,(ly:make-moment 3 4))))
> because the = must come immediately after the myNewAutoBeamSetting.
>
>>
>> The problem with context properties is there's nowhere to store the
>> previous value, hence why the following doesn't work:
>>
>> \relative c' {
>>   \set fontSize = #-5
>>   c4
>>   \once \set fontSize = #4.7
>>   c4
>>   % reverts to default size, rather than -5
>>   c
>> }
>>
>>> If so, are there any other context
>>> properties that might benefit from a similar push-down stack?
>>
>> Definitely.
>>
>> There's an issue logged for this related to midi, but it would be
>> useful in many other situations.
>>
>>> My knowledge of the internals is not sufficient to judge whether this
>>> is feasible or even possible, but is this an alternative approach
>>> worth considering?
>>
>> I'm sure it's possible, but it's way beyond my capabilities.
>>
>
> As I've continued to hunt around the scm/define-grobs.scm, I notice that
> completize-grob-entry sets the 'is-grob? property of each grob to #t.  We
> could define entries in that list for which 'is-grob? would be set to #f.

If you did that, you wouldn't be able to use \override and \revert on
those entries:

#(set-object-property! 'Script 'is-grob? #f)

\relative c' {
  \override Script #'color = #red
  c4->
}

warning: not a grob name, `Script'

> We could also probably change the name from all-grob-descriptions to
> something like all-description-properties, and description properties would
> include grobs and other descriptions that need \override and \revert.
>
> Is this a potential way to move forward?

I'm not qualified to make that call, but my gut feeling is it's a dead end.

Regards,
Neil