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

[Keith OHara]

On Sun, 06 Nov 2011 23:34:37 -0800, <address@hidden> wrote:

> http://codereview.appspot.com/5323062/diff/28002/lily/pure-from-neighbor-interface.cc#newcode96
> lily/pure-from-neighbor-interface.cc:96: && (grace == LEFT ? has_grace :
> !has_grace))
> On 2011/11/07 01:25:30, Keith wrote:
> > In fact, why even use a loop over grace-ness if the actions within the
> loop
> > occur only for one of two passes through ?
>
> I'm not sure what you mean...the actions apply for both passes.

Well, the condition we are commenting on is inside an if() that protects the 
only action in the loop over grace.
The loop takes action for just the one value of 'grace = (has_grace? LEFT : 
RIGHT);'.
The other statements inside the loop over 'grace' look to be loop-invariants.

I realize that do{}while(flip()!=LEFT) is a LilyPond idiom, but in this case it 
seems more clear to update array element that needs it, without looping over 
the other case.

> This is saying "if the closest column is a grace-note-column, include
> the next-closest column as well."  This gets rid of any accidental
> overlap problems at the expense of potentially adding a little extra
> vertical space to the page-spacer calculations, but this extra space
> seems to be so minimal as to not be a problem (not unlike pure heights
> for beamed stems, which could also slightly overshoot their actual
> height).

I had not realized that the results of the pure-from-neighbor system influence 
the page-spacing.  This is inconvenient.  Now I have some idea why there is so 
much effort to increase the height only as much as needed.