2016-07-03 22:59 GMT+02:00 David Kastrup <d...@gnu.org>:
> Thomas Morley <thomasmorle...@gmail.com> 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
Ah, wasn't aware of that.
> (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
Many thanks again for the detailed explanation.
Federico,
as off issue 4908 you then could do:
Store this, (I named it atest-38.ly):
%%%%%%%%
\bookpart {
\header { title = "my-title" }
{ r1 }
}
\version "2.19.45"
%%%%%%%%
Then in a new file (I named it atest-37.ly):
%%%%%%%%
\version "2.19.45"
bkprt = \include "atest-38.ly"
\header { $(ly:book-header bkprt) }
\bkprt
%%%%%%%%
After compiling atest-37.ly:
$ exiftool atest-37.pdf
[...]
Title : my-title
Creator : LilyPond 2.19.45
As wished for your use-case.
Well, it's one file more, but you can still
use/include/do-whatever-you-want with atest-38.ly
Cheers,
Harm
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
