[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-bug
Subject:    Re: strange behaviour of \layout block variable
From:       Urs Liska <lilyliska () googlemail ! com>
Date:       2012-05-21 0:03:50
Message-ID: 4FB98666.2070601 () googlemail ! com
[Download RAW message or body]

Am 20.05.2012 23:12, schrieb David Kastrup:
> Urs Liska<lilyliska@googlemail.com>  writes:
>
>> Hi list and Gurus,
>>
>> I encountered a strange behaviour with a layout block assigned to a
>> variable.
>>
>> As advised on lilypond-user I write
>>
>> % Definition of \layout block in variable
>> % overrides a property
>> layoutVariable = \layout {
>>    \context {
>>      \Score
>>      \override Hairpin #'style = #'dashed-line
>>    }
>> }
>>
>> which I can then reference with
>>
>> \layout { \layoutVariable }
>>
>> This seems to work but it interacts strangely with other \layout
>> blocks written literally (or in include files).
>>
>> Normally, multiple \context definitions get merged so they all
>> apply.
> Nope.
>
>> If there are overrides of the same properties the last one will apply.
> This is a misunderstanding of what actually happens here.
>
> \layout { ... }
>
> is the same as
>
> "$defaultlayout" = \layout { ... }
>
> and
>
> "whatever" = \layout { ... }
>
> starts from the current state of $defaultlayout (unless ... starts with
> a layoutvariable which is then copied instead), adds ... to it, and
> assigns the result to "whatever".
>
> So whenever you reference a layout variable as the starting point inside
> of \layout { ... }, all changes made to $defaultlayout (by having a
> layout definition not assigned to a layout variable but written
> standalone) since creating the layout variable are lost.
>
> So \layout { ... } has an implicit starting point of $defaultlayout, and
> an implicit target of $defaultlayout, and either can be replaced with
> something else, the first by referencing a layout variable at the start
> of ..., the second by assigning to a layout variable.
>
> What you see here is consistent with this action of \layout.  Perhaps
> this might be considered a documentation issue (I think layout variables
> are documented rather lousily if at all), but the behavior itself is
> quite what to expect.
>
Hi David,

thank you for the detailed explanation.
I think I did understand it but there remain a few open questions.

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?

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?
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 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.

Best
Urs




[prev in list] [next in list] [prev in thread] [next in thread]