lilypond-user
[Top][All Lists]
Advanced

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

Re: \set vs \override


From: David Kastrup
Subject: Re: \set vs \override
Date: Tue, 24 Nov 2009 02:10:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Mon, Nov 23, 2009 at 12:55 PM, David Kastrup <address@hidden> wrote:
>> Han-Wen Nienhuys <address@hidden> writes:
>>
>>> On Mon, Nov 23, 2009 at 3:56 AM, David Kastrup <address@hidden> wrote:
>>>
>>>> Right now I don't have the necessary clue level.  Merely a gut hunch.
>>>
>>> Why dont you invest some time to find out how it really works,
>>
>> What do you think I am doing?
>
> I think you send a lot of mail.  I suggest reading code; if it were
> easy, where would the fun be?

I read the code.  I read the documentation.  I wrote stuff that worked
in contradiction to the documentation.

> As a hint:
>
> * context properties are time-dependent, exist per Context, and have
> different values during the translation process (eg. the key
> signature, which is at staff level and changes if you change the
> keysig).
>
> * grob-properties are part of the formatting process, and are per
> graphic object. Formatting the score is computing the value of each
> grob property
>
> * grob properties have defaults (an alist, one per grob type), and
> those defaults are stored in a context property. see
> scm/define-grobs.scm
>
> * \override and \revert manipulate the defaults stored in said context
> property, pushing and popping values off the alist.

This concise "hint" is wagonloads clearer than what is in the "\set vs
\override" documentation node.  The documentation can be strictly
improved by throwing out what is there and putting this hint in.

But while the hint addresses the difference and relation between those
properties much much clearer than the manual, it still does not mention
why one set of properties should only be manipulated with \set, and the
other only with \override/\revert.  It does not appear that there is an
actual technical necessity for this, but rather it would appear that the
basic nature of the different properties makes one or the other
typically more feasible.

-- 
David Kastrup





reply via email to

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