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

[lilypond]

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