Nathan Chou <starry...@gmail.com> writes: > Hello, > > Thank you for the information! I have been thinking more and a few > questions have come to mind: > > * However the cross voice Spanner object is created, is it expected to > be identical to the object currently created by the hidden voice > workaround? Just to make sure, Spanners are Grobs, which only contain > graphical information and aren't associated with a context, right?
Spanners are Grobs. Grobs contain a whole lot more than only graphical information (the graphical part is their stencil) but are employed only during graphical typesetting (the one governed by \layout blocks). Spanners tend to split into separate quasi-items at line breaking, with each such item covering one line. They aren't themselves associated with contexts, but the _announcements_ (or rather "acknowledgments") of grobs mention the engraver originating the announcement. That engraver is hosted by a particular (and queryable) context. > * Although it is possible to deliver the STOP spanner event to the > engraver of the corresponding START event (e.g. if the spanner has an > ID to match the START and STOP events), is this an undesirable > solution because it basically does the same thing as the hidden voice > workaround? There is no need to base the implementation on workarounds. At the current point of time, slurs and phrasing slurs have ways of dealing with multiple spanners. That has not much of a user interface and it requires putting up engravers in some context where it will see the announcements of both starting and ending slur. The mechanism is also tied rather hard into the engravers themselves without a good way to generalize this into other engravers. Currently engravers listen to events and acknowledgments only in their dedicated context but can announce anywhere. It's possible to move the listeners around independently if that opens a viable solution. Of course, the lifetime of an engraver is tied to its hosting context, however. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel