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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel