Urs Liska<address@hidden> writes:
Do I understand correctly that if I write
\layout { ... }
I actually take
"$defaultlayout"
as a starting point, add something to it and assign the result to
"$defaultlayout"
?
So if I write \layout { ... } for the second time the additions from
the first time are reflected because they had been assigned to
"$defaultlayout" during the first run?
Yes and yes.
Now I take my example file to see if I really understood:
% \first \layout block overrides one property
\layout {
\context {
\Score
\override Hairpin #'color = #magenta
}
}
This overrides the color of the Hairpin.
Now this override is stored in "$defaultlayout"
% second \layout block overrides a second property
\layout {
\context {
\Score
\override Hairpin #'thickness = 3
}
}
What is taken as the starting point here already contained the
previous color override?
Now the Hairpin is printed magenta and with thickness 3.
If that's right then I'd say that (from a users perspective) the two
overrides are merged, isn't it?
The overrides are on different non-overlapping properties, so they are
accumulated rather than merged.
And if the second \layout block also overrides the color (i.e. the
same property) the second value is in effect, isn't it?
So what was wrong with my respective assumptions in the OP?
I don't see anything wrong in the _written_ assumptions. Perhaps the
misunderstanding is that you consider context definitions as independent
from layout blocks, and just placed syntactically inside of them for
some unfathomable reason. But each layout variable (including
$defaultlayout) has its own set of context definitions. You can't
actually _change_ context definitions using LilyPond rather than Scheme
code. If you write something like
\context {
\Score
\override Hairpin #'thickness = 3
}
This creates a _copy_ of all definitions in the current Score context
def, adds an override to it, and uses the result as a new context def.
This new context def is then used for Score because it contains a
\name "Score" definition, from the copy of the original Score context
def.
I now understand how this behaves when layout variables are involved.
But I have to admit that this is quite strange and only manageable
with some very thorough explanation.
I am not privy to the design. The only advantage I have before you is
that I have read what this does in the parser code I had to work with.