Luca Fascione <[email protected]> writes: > On Thu, Aug 27, 2026 at 4:49 PM David Kastrup <[email protected]> wrote: > >> The problems essentially are: books and bookparts are hard to >> distinguish at all right now even though there are two different >> keywords to create either of them, and there are things you should not >> be doing with one or the other, and those things are supported with data >> fields of their own. > > > So I have a question: you have a bookpart object, and this I'm guessing is > conceptually > a sequence of... scores or so, right?
Scores, markups, page marks, headers, optionally layout paper blocks. > My question is: what's the business of a book object being able to > _actually_ be a bookpart, Are you talking about a LilyPond \book object here or a C++ Book object? Those are different things. > why can't the book just be a sequence of bookparts instead? Because its headers, paper blocks and layout blocks provide defaults for that of the bookparts. > Like, in the source lilypond file you can just make a Staff in the > middle of nothing, and the program will make for you a Score to wrap > it, right? What is the defense for not doing the same thing with books > and bookparts? (ie. bookpart only ever is an "honest" bookpart, and if > there is a need to treat it like a book, a Book is made on your behalf > and placed "around it", like the Score and Staff relation). I suggest you take a look at what actually happens before complaining that it doesn't happen. Also how toplevel music and scores and books and bookparts are treated is done in hooks that the user is free to redefine. -- David Kastrup
