Re: Doc: NR: Move "Modifying alists" from 4.1.2 to 5.3. (issue2767043)

[Carl . D . Sorensen]

On 2010/10/31 21:54:41, Mark Polesky wrote:
> This patch...

> 1) adds a node to NR 5.3 "Modifying properties" that
>     explains alist-modifying in a generic way, and

> 2) removes the similar material from
>     NR 4.1.2 "Page formatting".

> However, there are two statements I want to make, but I'm
> not certain if they are entirely true:

> 1) If an alist is a grob property or \paper variable, its
>     keys can be modified individually without affecting other
>     keys.

> Is this true for all grob properties and \paper variables?
> Are there any other classes of alists that allow setting
> keys individually with nested declarations?

I think this is right for grob properties that are nested property
alists, meaning that the keys are symbols.  As far as I know, this is
true of all the grob alists.


> 2) Nested declarations will not work for context property
>     alists (such as beamExceptions, keySignature,
>     timeSignatureSettings, etc.).  These properties can only
>     be modified by completely re-defining them as alists.

timeSignatureSettings and beamExceptions are not nested property alists.
 They are properties with alist values.  The keys to the alist that is
the property value are not symbols, so the standard nested property
alist methods don't apply there.

Also, grob properties can be modified with \override, so the new
property is prepended to the old, and the old properties still exist.

Context properties cannot be modified with \override.  They must be
modified with \set, which redefines the full value of the context
property and thus requires the full alist to be given.  We had a
discussion a while ago, and Han-wen was opposed to using nested
overrides for context properties, so I developed a special handler for
timeSignatureSettings.

So in summary, I believe your statements are correct.

Thanks,

Carl


> Is this correct?  Or are there some context property alists
> that can accept a nested declaration to set one key?  If the
> statement is incorrect, is there a pattern to the
> exceptions, or is it some sort of case-by-case basis?

> If both statements are correct, is this okay to push?

> Thanks!
> - Mark



http://codereview.appspot.com/2767043/