lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]