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

[lilypond]

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

I quote your comment 6:

    The patch in comment 1 restores the former behavior, for the slur  
patterns created when the part-combiner merges two streams into one voice:
      { <c e>(( <d f>))  <c e>(( d) c( <d f>)) }
    All of these should show a single slur ending on the d.

And now your comment 10:

    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.

You claim that

    <c e>(( d) c( <d f>))

should be interpreted as

    <c e>( d) c( <d f>)

and that previously flagged warnings were erroneous so that the
previous behavior was well-defined (and thus the current situation a
regression) in spite of giving off warnings, and cite the behavior of
multiple \clef commands (property changes rather than events, let
alone spanner events) as reference.

Here is an example for another spanner under the reign of the part
combiner:

\layout { \context { \Voice \consists "Horizontal_bracket_engraver" } }
\partcombine
  {e'2\startGroup f'4 g'\stopGroup g'2\startGroup f'\stopGroup}
  {c'2\startGroup f'4 g'\stopGroup e'2\startGroup d'\stopGroup}

In your opinion, is that a problem of the bracket engraver or of the
part combiner?

The "conflate multiple slur events" has the advantage of making it
easier to deal with the doubleSlurs setting.  It is likely the
cheapest path forward without fixing the part combiner, at the cost of
not warning about several cases of manual input rather unlikely
reflecting the intent of the user.

If you take a look at the history of issue 1967 which has first been
renamed from a partcombiner problem to a slur problem, and then be
declared "Fixed" after I committed the workaround while the discussion
clearly points out that the partcombiner is deficient, this seems like
a rather sloppy way of evading the problem.  And with the analysis
brackets, the approach to simply disable warnings and choose a
partcombiner-friendly interpretation for otherwise likely invalid
input does not work, since the output produced by the partcombiner is
valid on its own (though not corresponding to the input), and so can't
be creatively reinterpreted as something different.


Attachments:
        junk.preview.png  5.4 KB