Re: PDF metadata missing if \header is within a \bookpart block

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Nevertheless, I tried a workaround for single bookparts with a build
> including issue 4908.
>
> (1) This works as expected:
>
> hdr = \header { title = "my-title" }
>
> %#(format #t "~y" (ly:module->alist hdr))
>
> \header { \hdr }
> { r1 }
>
> $ exiftool file.pdf
> returns
> [...]
> Title                           : my-title
> Creator                         : LilyPond 2.19.45
>
>
> (2) This one not:
>
> hdr = \header { title = "my-title" }
>
> bkprt =
> \bookpart {
>   \header { \hdr }
>   { r1 }
> }
>
> %#(format #t "~y" (ly:module->alist (ly:book-header bkprt)))
>
> \header { #(ly:book-header bkprt) }
> \bkprt

> What's the essential difference?

Essentially \hdr vs #hdr .  At top level and in blocks with modules
(namely anywhere where assignments make sense) the results of #xxx get
ignored since commands like #(set! (hashq-ref ...)) can actually return
values and where LilyPond accepts assignments, assignments using
#(set!...) must equally be expected, and there are function calls like
#(set-whatever-point-size) that also tend to be written in a manner not
painstakingly avoiding returning anything.

So \header { #(ly:book-header bkprt) } does nothing and needs to be
written as \header { $(ly:book-header bkprt) } instead.  While #...  is
ignored in locations accepting environments (so not within music
expressions), $..., \... (including anything defined with
define-scheme-function which is why there also is define-void-function)
is not.

In Scheme, it depends on the context whether a return value is ignored.
LilyPond's visible context is often a lot less obvious.

Yes, I was confused at first as well and printed #{ \header { } #} with
your print statement to see what was up here.

By the way: #(format #t ...) also does not return a well-defined value
(according to the Scheme standard; Guile might or might not be different
here) so it's nice for debugging to have the return value ignored in
such contexts.

-- 
David Kastrup