What should the relation between \book / \bookpart be?

Simon Albrecht <[email protected]>
Newsgroups gmane.comp.gnu.lilypond.devel
Message-ID <[email protected]>

OK. I know this is complicated and hard to discuss without extensively 
looking at real-world examples. I’m trying ;) and hoping the attached 
“diagram” may help…

On 08/08/2026 13:50, David Kastrup wrote:
> Your nested book statement may actually look like \include
> "volumeIII.ly" for a compilation of standalone pieces in one PDF.
>
> It could also look like
>
> volumeI = \book { \include "volumeIII.ly" }
>
> \book {
>    ...
>    \bookpart { \volumeI }
>    ...
> }

I’m not sure whether the mixture of I and III in that example was 
intentional and if so, why. Assuming it wasn’t:

It seems like you want to allow for a project structure like [A]* where 
every file contains its own \book and (if necessary) \bookpart 
environments, such that each and every file can be processed on its own 
returning output files. However, that leads (IIUC) to the logic issues 
you’ve been trying to describe and address.

I would argue that the same can always (?) be achieved with a structure 
like [B]* where there are “content” files (for clarity appended with 
.ily) that never contain \book environments and “output” files that 
always do. Depending on the project \bookpart may be used in either one 
or the other, or even in an intermediate layer of .ily files.



On 08/08/2026 13:50, David Kastrup wrote:
> The point is that they would not, in effect, be nested book
> environments.  In execution, the nested book would be downgraded to act
> like a bookpart in that it would not produce a file of its own but be
> part of the surrounding book.
>
> What that means for things like "number-by-bookpart" is of course a
> recipe for further headaches.

If they would not, in effect, be nested book environments, then they 
shouldn’t be declared as such in the input file, I think. What about 
defining a new kind of environment that simply wraps up a number of 
elements (like \scores and \markups) to be output in sequence, without 
specifying their use in \bookpart or \book? I don’t think I have the 
right catchy name for that, but something like
\outputSequence {}
\outputColumn {}
\outputLines {}
if you get what I mean?

I suspect that would avoid those headaches you refer to. Such an 
environment could be arbitrarily nested since it doesn’t imply

This “wrapping up” could be achieved by putting that sequence of 
elements in its own input file and \including that where needed, but it 
would be nicer to be able to assign it to a variable, I understand.

Best, Simon
CAMERA_20260808_145639_2123441617755651261.jpg (image/jpeg, 83.6 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.