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, <[email protected]> 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/
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
