On Sep 24, 2020, at 10:28, Aaron Hill <lilyp...@hillvisions.com> wrote: > > I doubt this is the sort of thing convert-ly could patch, so the proposed > change in behavior would break user-created engravers that expect to always > get a pair of (start|stop)-translation-timestep calls. As such, it makes far > more sense that LilyPond automatically take care of invoking > start-translation-timestep after initialize.
This could probably be done (I'm not looking at the code right now), but then what would it mean to start a timestep? Starting a timestep would not be a pass over existing engravers, calling their start-translation-timestep methods with nothing in between. When an engraver is told that the timestep is beginning, it might actually mean that the current timestep began a while ago and an unknown number of other engravers have since done some processing other than what's in their start-translation-timestep methods. > The argument for uniform behavior is sound, though one must be careful the > behavior to which you are aligning is correct. My vote is that "starts" and > "stops" must always be paired. If there were cases where "start" was not > occurring, *that* is the faulty behavior to address. I understand your point, but I don't see that that can be achieved without abusing the current terminology. Changing it to work this way and renaming the methods to describe reality might be reasonable. — Dan
