[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (scheme-)engraver in 2.20/21
From: |
Dan Eble |
Subject: |
Re: (scheme-)engraver in 2.20/21 |
Date: |
Thu, 24 Sep 2020 12:43:51 -0400 |
On Sep 24, 2020, at 10:28, Aaron Hill <lilypond@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