Nathan Chou <starry...@gmail.com> writes: > Hello, > > I have somewhat looked at the code and want to confirm my > understanding of the current behavior: > * While the file is parsed in Scheme, spanners cause a START and STOP > event with an appropriate type to be created in the context they > belong to
Ties are also spanners but don't have a STOP event. It might be feasible to create the equivalent of a STOP event for them if it turns out necessary. > * After creation of the Music objects, where are they stored? Where they belong. Most objects are part of other music expressions. Every score has one top-level music expression. > Do iterators go through events from the same place? I have no idea what that means. > * Event iterators are eventually created and processed, causing the > spanner events to be dispatched to their contexts More or less. > * Engravers listen for event types they are interested in using > IMPLEMENT_TRANSLATOR_LISTENER (which I don't really understand at the > moment) IMPLEMENT_TRANSLATOR_LISTENER produces some startup code that enters a given member function of a translator into once-per-type alists (static member containing a list of callbacks). I'm currently working on making this a bit more C++-like instead of using C macros but it won't get significantly easier to understand I think. > * As an engraver processes events, it creates spanners with > make_spanner, which ultimately calls internal_make_grob and > announce_grob Something like that. > Assuming this is correct, I believe I would need to think of ideas for > engravers to be able to receive events outside of their context. Any > suggestions or things I should keep in mind? Engravers can already change their contexts with context-change events. I don't think that this is quite what you want however. Grobs/spanners may be announced to a context different from the context of the original engraver (see announce_grob and announce_end_grob and their optional argument). Slurs/Phrasing slurs have a labelling mechanism allowing multiple spanners in parallel under control of the same engraver. Maybe the machinery should made be more generic so that it works for more than slurs. Or it should be replaced by some mechanism that can easily create extra engravers on the fly. There are a few valid approaches. The important thing is to figure out something that's reasonably easy to make work by the programmers of engravers as well as easy enough to work with for users. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel