Translators use a two-step mechanism for reacting to stream events whereby they first record them in listeners, waiting to have gathered them all and for some early effects to happen like property sets, and then turn to their grob creation actions in process-music, at a point where writes are supposed to have happened so they can do reads.
This has a hole. Suppose you need to set some properties or otherwise take write action based on _all_ the events you collected rather rather than individual events each making for a property set. If you do it in process-music, you get dependency on the order of engravers or the hierarchy of contexts. There is no choice but to do writes in listeners, possibly recomputing the value of a property every time you get a new event to consider. Alternatively, you can arrange downstream translators to read the property in the acknowledge phase, which is not always possible or elegant. While rare, this does happen in practice. I have two use cases in mind. The first is the Bar_engraver. /* Bar_engraver should come *after* any engravers that modify whichBar This is a little hairy : whichBar may be set by Repeat_acknowledge_engraver::process_music, which is at score context. This means that grobs could should be created after process_music. We do stuff process_acknowledged (), just to be on the safe side. */ The Bar_engraver is doing its operation in process_acknowledged even though it does not acknowledge anything, which is clumsy. My current work on disentangling line breaks from bar lines involves changing a number of engravers so that they read context properties to determine whether a break is available instead of acknowledging bar lines. Some inelegance might be ok for a single engraver, but I'd rather not do this in half a dozen of them. Another use case that I recall is influencing pitches based on all the ones that are found, such as for naturalizing key signatures: https://lists.gnu.org/archive/html/lilypond-user/2021-04/msg00027.html The choice of naturalization is influenced both by note events and by any key signature events, so this engraver has to resort to recomputing stuff when a key signature is heard because process-music would come too late. Another similar instance where this would have been useful: https://lists.gnu.org/archive/html/lilypond-user/2021-04/msg00193.html To fill this hole, I am musing about adding a new translator slot called pre-process-music. The principle should be clear from the name: pre-process-music is called on all translators after all listeners, and before all process-music slots. It can be used for operation that needs all events heard but should happen before grob creation. No equivalent can be sensibly provided for acknowledgers since it remains possible in process-acknowledged to create grobs, thus starting new acknowledge cycles, so there is no logical grouping of the grobs seen in the same acknowledge cycle. Thoughts on the principle? Other ideas? Regards, Jean
