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
