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 (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 _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond