Hi,
I'm looking at this in terms of design inconsistencies rather than
documentation issues.
I've been looking around at the code and documentation regarding
contexts and noted these statements:
LM 3.3.2 says
"Note that there is no |\new Score| command;
*the single top-level |Score| context is introduced
with |\score|*."
(My bolding)
LM 3.1.1 says
"*Every |\book| block creates a separate output file (e.g., a
PDF file). If you haven’t explicitly added one, LilyPond wraps
your entire input code in a |\book| block implicitly.*
Every |\score| block is a separate chunk of music within a
|\book| block.
Every |\layout| block affects the |\score| or
|\book| block in which it appears – i.e., a |\layout|
block inside a |\score| block affects only that |\score|
block, but a |\layout| block outside of a |\score| block
(and thus in a |\book| block, either explicitly or
implicitly) will affect every |\score| in that |\book|."
(My bolding)
So, is the top-level block in a lilypond input file implicitly a book or a score?
Which is right, and do all places in the code make the correct assumption consistently?
There are a couple of parser variables relevant to \book output-count
and output-prefix (only output-prefix is still used as of 2.13.4). I
reckon output-prefix and possibly then the filename part of the output
filespec would be valid properties for \book. I also think Book would
be a valid context for these to live in.
However, at the moment contexts are designed to be part of the process
of translating music source code into final format of some sort (e.g.
.png, .pdf), and are associated with engravers and suchlike. The Book
context would be concerned with whereabouts that output was headed.
I had been thinking of adding all the parser variables as properties,
but have since had a look at the original list Marl Polesky generated
and have come to the conclusion parser variables seem to be a very mixed
bag: for things which are supposed to be user-settable this seems to be
because maybe the developer couldn't think of a place that fitted for
them: afterGraceFraction should have been an optional parameter to the
afterGrace function, and output-count and output-prefix should have had
some way of being attached to the \book in the lilypond language;
showFirstLength and showLastLength are associated with the
skipTypeSetting property which LR 3.4.2 lists as a score property so
show*Length should be in define-context-properties.scm where
skipTypesetting is defined. The rest of the parser variables look like
they are genuine internal things for use in Scheme code.
So, if \book is really the top of the tree, and a lilypond file is either:
* a series of \book blocks
* a single \book block
* an implicit \book block
And each book block of whatever sort contains either:
* a series of \score blocks
* a single \score block
* an undeclared, implicit \score block
Places in the code assuming "a single top-level score context" will need
fixing.
I would like lilypond to have a Book context sitting above Score in the
context hierarchy.
How could I add Book as a valid context?
I already understand how to add new properties to the lists in
define-context-properties.scm.
I haven't yet found out how \set, \unset, \override or \revert code
decides which of the property lists like all-music-properties,
all-translation-properties or all-backend-properties to search for a
valid property definition.
Thanks in advance for any help, tips, pointers or comments.
Cheers,
Ian Hulin
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
