[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: lilypond
Subject: Re: [Lilypond-auto] Issue 2584 in lilypond: please make partcombine merge slurs
Date: Mon, 04 Jun 2012 08:51:04 +0000

Comment #14 on issue 2584 by address@hidden: please make partcombine merge slurs

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]