lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \set vs \override


From: Joe Neeman
Subject: Re: \set vs \override
Date: Sat, 21 Nov 2009 15:24:34 -0800

On Sat, 2009-11-21 at 23:31 +0100, David Kastrup wrote:
> Joe Neeman <address@hidden> writes:
> 
> > On Sat, 2009-11-21 at 17:22 +0100, David Kastrup wrote:
> >> There is a chapter "set vs override" in the manual.
> >> 
> >> I am afraid that I fail to grasp the difference from the chapter.
> 
> [...]
> 
> >> If the element description is a _special_ type of context property,
> >> that would imply that there is just _one_ different kind of
> >> properties.  It completely fails to mention _what_ makes the element
> >> descriptions special and not settable with \set.
> >> 
> >>     These properties are named in `StudlyCaps' (starting with capital
> >>     letters).  They contain the `default settings' for said graphical
> >>     object as an association list.  See `scm/define-grobs.scm' to see
> >>     what kind of settings there are.  Element descriptions may be
> >>     modified with `\override'.
> >> 
> >> So why can't we use \set with element descriptions?  And where is the
> >> difference to context properties changing values?  After all, the
> >> principal purpose of \override is also to change the value, and
> >> \once\override very obviously changes behavior over time while
> >> interpreting music.
> >
> > Since \override works by modifying special context properties, you can
> > actually use \set for setting grob properties.  However, \override
> > does some extra useful work: for a start, it appends new overrides to
> > a list of overrides for a grob so that they can be easily reverted
> > (\set just clobbers the existing variable).  Also, \override supports
> > nested properties (useful for things like 'bound-details).  The
> > type-checking mechanisms are also different for \override and \set.
> 
> You describe different semantics for \set and \override.  Then you
> describe different restrictions.  And then you say that they have
> different type-checking mechanisms.
> 
> The problem is that the different type-checking mechanisms are there for
> the two different kinds of properties, but the whole thing appears
> completely arbitrary: it is not clear why you would want to permit one
> kind of command just with one set of properties, and the other with the
> other.  I see no connection between the type of command you should use
> and the kind of properties that are affected.
> 
> If you take a look at a recent proposal
> <URL:http://codereview.appspot.com/152127/patch/1004/5>, \tweak (another
> setter) is proposed to support nested properties.

\tweak works on the same set of properties, more or less, as \override.

> I don't see a good rationale why \set, \override, \revert, \tweak should
> not work on the same set of properties (including subproperties).  I
> don't see an explanation why it makes sense to differentiate between
> them.

\override works on grob properties. \set works on context properties.
They are distinguished by the fact that the properties belong to
different objects with different purposes (contexts exist to create
grobs; grobs are the graphical objects that are drawn in the end).

In the _implementation_, \override sets a context property which tells
the context that all future grobs should have those settings. So there
is a little bit of overlap between the two notions, but there are also
differences. For example, the beam-related context properties would not
make sense as grob properties because they are needed in order to decide
how many beams there should be, so once the beams have been created they
aren't needed anymore.

> And I am arrogant enough to believe that if I don't understand a design
> decision after a few days of trying, it is likely that ultimately a lot
> of people other than myself will be better off if the distinction gets
> abolished.

I think you would have a lot of trouble abolishing them, since there are
several grob properties that would not work as context properties and
vice versa.

Cheers,
Joe






reply via email to

[Prev in Thread] Current Thread [Next in Thread]