pre-process-music

[Jean Abou Samra]

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