Le 12/10/2021 à 15:33, David Kastrup a écrit :
but I don't even know whether there is a guarantee that ly:arpeggio::print is happy with the grob being modified after the call and before the stencil is getting used. Looking at the C++ code, that appears to be the case. Maybe giving ly:arpeggio::print an optional overriding direction argument could be cleaner? It doesn't help with creating user-level code for current LilyPond versions, of course.
Properties can be accessed from anywhere, provided no cyclic dependencies. If ly:arpeggio::print calls anything that also needs the arpeggio's direction, that will be cached and screw up. There are a number of bugs caused by evaluation of callbacks at a wrong point in time when the property has not been set by what was supposed to set it, and they are hell to track down because it's not always clear how execution was supposed to happen in the first place and sometimes things just worked by accident. So even though there may be no problem in this specific instance, I really don't think we would want to encourage this style of coding. A solution to this particular problem might be allowing several arpeggios in the same timestep. Best, Jean
