Re: Context_def -> Context progress

[Han-Wen Nienhuys]

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 - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com