On Wednesday 27 September 2006 22:05, Han-Wen Nienhuys wrote: > Erik Sandberg schreef: > > Hi, > > > > Here's a summary of my plans for the translator (I assume all of this > > will happen after 2.10): > > > > 1) separate context-def into two parts, translator information and tree > > information. Basically, the info shared by engraver-init and > > performer-init should belong to the 'tree information', which tells us > > the relationships between context types, while the stuff specific for > > layout and midi, such as translators and grob properties, should belong > > to the 'translator' part. 2) remove recurse_over_translator and friends, > > replace with a dispatcher system. This will probably be a slowdown, but > > not in terms of O. 3) softcode \consists, \remove as music functions. > > With the new event system, it shouldn't be difficult to add/remove > > translators on the fly. Depends slightly on (2). > > 4) remove Context::implementation. This member is currently only used by > > translator groups, to search for parents and children. Once (2) is done, > > it's sufficient to add a parent pointer to each translator group. > > > > This all sounds very good. Of course (3) implies that we'll be able to > run functions inside \translator definitions as well. I have the feeling > that this might be a can of syntactic worms. To address that I think > that it is better to do (1) before (3), because we can do (1) without > user-visible changes, i.e. we don't paint ourselves into backward > compatibility corners, while we gain understanding of how to do (3).
I have a clearer plan for context defs now: We could represent each context def as a Context object, which is used as a template for new contexts. E.g., the Voice context_def in engraver-init.ly defines a Context object with various engravers and properties in it, and when a new Voice is created during interpretation, the template voice is clone()d, and linked into the context tree. This requires a good mechanism for context cloning, which preserves translators and context properties. This can be achieved using signals, much like the AnnounceNewContext mechanism: Context::clone sends a CloneContext event, containing a reference to the newly created context. When the translator group hears this event, it clones itself and all translators, and connects the clones to the new context (this should be sufficient to preserve \consists etc.) This suggestion does still not make clear how to separate translator-specific and context-hierarchy-specific information, but we can wait with that separation. Plan: - create a Context::clone, which copies nothing. - replace lots of references to Context_def with references to a Context which references that context_def. - add hooks for translator groups (CloneContext event) - incrementally stuff out from context def to context and translator group. This includes the commands \consists, \remove, \type,\override, \revert, \set and \tempo. -- Erik _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
