Comment #7 on issue 2584 by [email protected]: 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.
