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
