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: David Kastrup
Subject: Re: strange behaviour of \layout block variable
Date: Sun, 20 May 2012 23:12:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

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.

-- 
David Kastrup




reply via email to

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