Erik Sandberg escreveu:
However, while I wrote this, I have been thinking about an alternative
solution to the same problem, which is cleaner but less efficient: We could
let context_def simply be a music expression which is inserted before any
music in the context. So e.g., \context Staff { c4 } would be equivalent to
creating a new, blank context and interpret { \Staff c4 } in it.
A problem with this approach is that all property, \override and \consists
operations have to be re-iterated for each newly created context. This
doesn't need to take much time (quote-like constructs could be used to cache
the result of music interpretation), but the problem is that the size of
music streams would explode: Each Staff creation will send a bunch of
\consists and \set events to the new context, this may result in grotesque
music stream sizes if << \\ >> is used a lot. This weakness is at the same
time a strength, because music streams will be completely self-contained in a
natural way (currently they rely on knowledge about context_defs). The
concept of context_defs will be kept entirely on the iterator side, which is
very nice IMO. OTOH, it may be more difficult for non-lilypond applications to
distinguish between e.g. staff contexts and voice contexts, since that info
is not part of the CreateContext stream event.
I think this is a bad idea, because the receiving (non lilypond) will
lose all information regarding meaning of contexts, and rather get a
bunch of layout related property settings. I think the context are
analogous CSS style sheet. If it is problem, the context settings should
be transmitted separately, perhaps as some sort of header to the music
stream.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
