Re: Issue 2584 (redo 1967): please make partcombine merge slurs (issue 6294047)

[Keith OHara]

I wasn't very clear with fragmented codereview comments below.

There is one new problem, with slurs silently dropped in
  \partcombine {c''2^( d'')} {c'2( d')}

The problem is avoided if get_property("direction") is replaced with get_pure_property(), 
but I don't like the idea of having even more code require understanding of "pure".  
Better might be to cache the first explicit direction on a slur-start-event this time-step.

Another solution is to do what version 2.14 did and ignore all but the first 
slur-start-event we see (but keep the new more intelligent filter for warnings).


On Wed, 18 Jul 2012 16:00:14 -0700, <address@hidden> wrote:
> http://codereview.appspot.com/6294047/diff/4/lily/slur-engraver.cc
> File lily/slur-engraver.cc (right):
>
> http://codereview.appspot.com/6294047/diff/4/lily/slur-engraver.cc#newcode220
> lily/slur-engraver.cc:220: ev->origin ()->warning (_ ("already have
> slur"));
> You could simply finish here, with
>      }
>      start_events_.erase (start_events_.begin () + i);
>      break;
>    }
> replacing everything through line 258.  Then you simply keep the
> direction of first slur-event you saw.
>
> http://codereview.appspot.com/6294047/diff/4/lily/slur-engraver.cc#newcode238
> lily/slur-engraver.cc:238: // be decidedly strange for manual input.
> When each of the parts being combined is a few pages long, I find I
> write a few inconsistencies equivalent to
>
>    \partcombine {c''2^( d'')} {c'2( d')}
>
> The slurs are then silently dropped, for complicated reasons.
>
> http://codereview.appspot.com/6294047/diff/4/lily/slur-engraver.cc#newcode246
> lily/slur-engraver.cc:246: Direction slur_dir = to_dir
> (slurs_[j]->get_property ("direction"));
> This call might wait to see the layout under the slur, including effects
> of line-breaks, before reporting back.  If you understand "pure" in
> LilyPond, you can use get_pure_property()
>
> http://codereview.appspot.com/6294047/