2009/5/1 Carl D. Sorensen <c_soren...@byu.edu>: > > > > On 4/26/09 9:31 AM, "Neil Puttock" <n.putt...@gmail.com> wrote: > >> 2009/4/26 Trevor Daniels <t.dani...@treda.co.uk>: >> >>> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel