Re: (scheme-)engraver in 2.20/21

[Aaron Hill]

On 2020-09-24 5:15 am, Jan-Peter Voigt wrote:
> Hi Dan,
>
> Am 24.09.20 um 13:42 schrieb Dan Eble:
> > On Sep 24, 2020, at 05:51, Jan-Peter Voigt <jp.voigt@gmx.de> wrote:
> > > Hi all,
> > >
> > > after some other very involving projects I can now refocus on 
> > > lilypond :-)
> > >
> > > I probably missed a change in 2.20/21. If I create a scheme-engraver 
> > > the
> > > "start-translation-timestep" slot is not called, if the "initialize"
> > > slot has been called in this particular timestep. If this the 
> > > intended
> > > behaviour I appreciate it because it is consistent. The 
> > > "start-trans.."
> > > slot wasn't called before for instant voices, but for regular 
> > > installed
> > > contexts. So now I have to finish "initialize" of the engraver with
> > > "start-trans..." in any case.
> > >
> > > So my question is if this is intended and not likely to change?
> > > Sorry, if I missed discussion about this!
> >
> > This change was intended.
>
> thank you!
> I stumbled across this looking at the edition-engraver.
> Even though Aaron's objection is not entirely unjustified, I prefer 
> this
> uniform behavior. That means, the last action of "initialize" is always
> "start-trans...".

The make-engraver macro does not provide a means to manually invoke the 
start-translation-timestep procedure from the initialize procedure.  One 
would have to explicitly define a common procedure to be invoked in both 
cases:

%%%%
\consists
#(make-engraver
   ((start-translation-timestep trans)
    (format #t "\nstart ~s" trans)))

%% would have to become something like...

\consists
#(lambda (context)
  (define (handle-start trans)
    (format #t "\nstart ~s" trans))
  (make-engraver
    ((initialize trans)
     (handle-start trans))
    ((start-translation-timestep trans)
     (handle-start trans))))
%%%%

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.

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.


-- Aaron Hill