bug-lilypond
[Top][All Lists]
Advanced

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

## Re: strange behaviour of \layout block variable

 From: Urs Liska Subject: Re: strange behaviour of \layout block variable Date: Mon, 21 May 2012 02:03:50 +0200 User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

```Am 20.05.2012 23:12, schrieb David Kastrup:
```
```Urs Liska<address@hidden>  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

```

reply via email to

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