Comment #14 on issue 2584 by [email protected]: please make partcombine merge slurs
http://code.google.com/p/lilypond/issues/detail?id=2584
We are going in circles. You can't state "LilyPond does not support concurrent slurs" while arguing that there are exceptions, and then let LilyPond try to support concurrent slurs generated by the partcombiner without using a distinctive spanner-id like those used in the exception.
It does not make sense. The parser can't fix ambiguities. Let's try to make sensible rules here. I propose the following:
a) parens need to be matched in count. Without that rule, we conceptually have a master ( hanging in the sky forever, since the first opening paren could match as many closing parens as imaginable.
b) nested/multiple parens either need a common starting point, or a common ending point so that _all_ combinations starting with ending parens are equivalent. Everything else warrants a warning.
Can we agree on that being sensible behavior? If we can, we "just" need to make sure that the partcombiner does not change the net amount of parens it issues. Maybe that is already the case.
