lilypond-auto
[Top][All Lists]
Advanced

[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 07:53:56 +0000

Updates:
        Labels: -Patch-needs_work Patch-new

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

The partcombiner is not producing garbage, but a reasonable description of the slurs it wishes to be engraved. For the example at the top of this issue, \partcombine produced two simultaneous start-events for the same slur (having the same spanner-id) and one end-event. But the slur-engraver should know from the spanner-ids that these events refer to a single slur.

Regtests. The original slur-multiple is changed as shown in the image. The text for this test says : "LilyPond does not support multiple concurrent slurs with the parentheses syntax. In this case, warnings will be given and the nested slur will not be generated. However, one can can create a second slur with a different spanner-id." After the patch for issue 1967, the test started to draw a concurrent nested slur from input using the parentheses syntax, contradicting the test description. This patch restores correct behavior.

The regtest shows a new line in the log files for phrasing-slur-multiple.ly and slur-multiple.ly,
  warning: 1 expected warning(s) not encountered: already have slur
because these two tests expected a warning from the attempt to start two slurs with c4((. However, \partcombine can produce that same slur pattern, and according to issue 1967 we do not want that warning.

So I still want to update the input for these two regtests to contain erroneous input for which we /do/ want to give warnings. Expect patchy to show the updated versions of these two tests.

Reposted as a patch series showing the revert of the original fix for issue 1967, followed by a re-implementation of the fix, to produce the same final patch as in comment 1 :
http://codereview.appspot.com/6272046/

Attachments:
        restore.png  22.1 KB




reply via email to

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