Updates:
Status: Started
Comment #32 on issue 2801 by [email protected]: Patch: Approximates cross-staff
slurs in VerticalAxisGroup vertical-skylines.
http://code.google.com/p/lilypond/issues/detail?id=2801
Mike, I just looked at the patch, and you have a totally separate set of
Slur properties for SlurStub. Any override of Slur properties will not end
up in the SlurStub properties. You fix a few cases, like \slurUp and
\slurDown, but that is totally unrobust and a recipe for disaster since the
normal case now will be that the behavior of slurs and slur stubs will
diverge as soon as you override one.
Also tweaks on the slur will not end up on the slur stub. One remedy might
be to take a look at the definition of grob::calc-property-by-copy and
create something like grob::calc-property-by-grob-copy that will not use
event-cause but rather the immediate grob cause for its initialization and
use it like grob::calc-property-by-copy is used in scm/define-grobs.scm. I
am not sure that there will not be an even better way than
element-by-element cloning, but that seems like the fastest remedy for me
right now and allows individual tweaks and overrides in the grob
definitions themselves and by the user.
The code, as it currently stands, is a disaster because SlurStubs and Slurs
will diverge as soon as you try any manipulation of Slur properties.
I don't understand how it does not trigger your self-review reflexes when
you have to change the definitions of things like \slurUp. There are
frequent discussions on the mailing list about things like tweaking the
control points and many other aspects of Slurs, and all those will break if
you initialize SlurStubs independently from their causing Slurs.
Please fix this as soon as possible.
