Re: Axis group interface ignores column rank for pure-from-neighbor-interface (issue 5843063)

[k-ohara5a5a]

Yippee; no more grobs getting their pure_height from their neighbors!

Don't forget to update the commit message.  You can also "edit this
issue" to update the title and summary here on Rietveld.


http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly
File input/regression/pure-from-neighbor-interface-pure-height.ly
(right):

http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly#newcode1
input/regression/pure-from-neighbor-interface-pure-height.ly:1: \version
"2.15.34"
.35
The title makes less sense now.  "lyrics-spanbarstub.ly" ?

http://codereview.appspot.com/5843063/diff/7/input/regression/pure-from-neighbor-interface-pure-height.ly#newcode4
input/regression/pure-from-neighbor-interface-pure-height.ly:4: texidoc
= "@code{axis-group-interface::pure-height} does not take spanned
The description no longer fits.  Maybe
"empty measures do not confuse SpanBarStub.  These lyrics should remain
clear of the span bars."

http://codereview.appspot.com/5843063/diff/7/lily/item.cc
File lily/item.cc (right):

http://codereview.appspot.com/5843063/diff/7/lily/item.cc#newcode245
lily/item.cc:245: cache_pure_height (Grob::pure_height (this, 0,
INT_MAX));
This commit :
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=9fe7859a8592a080413b744e3768db41059dbfe3
depended on having 'start' and 'end' passed through, so we should put
this back.

Caching in this way assumes that the pure_height of an Item is
independent of where the line-breaks are.

Anything that gets pure_height from its neighbors would break that
assumption, but now it seems there are no such Items, as they all use
pure-from-neighbors-interface to set their extra-spacing-height.

Tied accidentals break that assumption as well, but that's not our
fault.  I'll write a cautionary comment in a separate commit.

http://codereview.appspot.com/5843063/diff/7/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/5843063/diff/7/scm/define-grobs.scm#newcode1883
scm/define-grobs.scm:1883: (Y-extent . (1 . -1))
I suggest (Y-extent . #f)
because (1 . -1) looks so much like (-1 . 1), and it also makes
suspicious people like me think it is an uncommented magic number.

http://codereview.appspot.com/5843063/diff/7/scm/output-lib.scm
File scm/output-lib.scm (right):

http://codereview.appspot.com/5843063/diff/7/scm/output-lib.scm#newcode437
scm/output-lib.scm:437: (let* ((height (ly:grob-pure-height grob grob 0
10000000))
The C code uses INT_MAX to represent the end of the whole score, so it
would be nice to use the same here, if possible.

http://codereview.appspot.com/5843063/