Re: [Lilypond-auto] Issue 2801 in lilypond: Patch: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines.

[lilypond]

Updates:
        Status: Started

Comment #32 on issue 2801 by address@hidden: 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.