Re: [Lilypond-auto] Issue 2584 in lilypond: please make partcombine merge slurs

[lilypond]

Comment #7 on issue 2584 by address@hidden: please make partcombine merge  
slurs
http://code.google.com/p/lilypond/issues/detail?id=2584

The description of the patch states that the partcombiner can produce the  
following kind of patterns:
{ c(( d)) } or { c(( d) } or { c( d)) }
I have a hard time swallowing that we should consider all that valid input  
without the need of a warning.  In particular, if
{ c(( d) }
is supposed to be valid, and
{ c(( f) e) }
is also supposed to be valid, then there is no way whatsoever to guess  
whether
{ c(( f))( e) }
is supposed to be reduced to
{ c( f)( e) }
or
{ c(( f)( e)) }

So I think that this _can't_ reliably be fixed in the slur engraver alone.   
Instead we need to make the partcombiner produce sane patterns given sane  
input.  The patterns that currently come out of it _can't_ be interpreted  
without ambiguity.

The slur engraver current has to work with garbage-in from the  
partcombiner, and it has changed the cases where it produces garbage-out.   
Since the partcombiner never produced anything but garbage, I have a hard  
time picturing this as a regression.  It is just that we now deal  
differently with a problem that is impossible to solve given the unchanged  
output of the partcombiner.