Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

[k-ohara5a5a]

> >> Pure relevant is used all over the code.
> >
> > Good point.  There is even a predicate 'pure-relevant?'
> > defining which grobs qualify.
> >

> Exactly.  This is how the Pure_from_neighbor_engraver
> evaluates which grobs have
> pure height functions (line 49).



http://codereview.appspot.com/5323062/diff/29001/lily/pure-from-neighbor-engraver.cc
File lily/pure-from-neighbor-engraver.cc (right):

http://codereview.appspot.com/5323062/diff/29001/lily/pure-from-neighbor-engraver.cc#newcode49
lily/pure-from-neighbor-engraver.cc:49: SCM pure_relevant_p =
ly_lily_module_constant ("pure-relevant?");
Now, this fills 'items_' with things that pass the 'pure-relevant'
test.
(Since you say Item as opposed to Grob, do you exclude slurs and such?)

http://codereview.appspot.com/5323062/diff/29001/lily/pure-from-neighbor-engraver.cc#newcode60
lily/pure-from-neighbor-engraver.cc:60: pure_relevants_.push_back
(i.item ());
But 'pure_relevants_' is something different from simply things that
satisfy the predicate 'pure-relevant?'.  It looks like it includes only
items in the immediately-adjacent columns.

This would seems to let accidentals on the second-neightbor-column cross
the extended bar lines. How would this (untested) work?

  \new PianoStaff <<
  \new Staff { R1*4 }
  \new Staff {
    e'1 | \acciaccatura e'16 <e'' cis''' dis'''>4 r2. |
    \slurUp \acciaccatura c''16 <c' fis gis>4 r2.
    <c' fis gis>4 r2.
  } >>

http://codereview.appspot.com/5323062/