Where's the point? We don't use that kind of arrangement in our code, and it's not efficiently doable anyway.
A conceivable application would be for determining systems spacing manually (for example, generating sequences of TeX \vspace and \break for LilyPond-book that will reserve normal rectangular space at page breaks, but interleaving staff spacing when not broken), but this function is mostly useless for that purpose. One can only indirectly try to guess the size of the spacing, one can't reuse a skyline pair(!) when one wants to compare against several neighbors (requiring _two_ calculation of each skyline pair when assembling a vertical arrangement), and the spacing is appears to be determined differently than the vertical spacing engine does it usually. And for emulating vertical spacing, the stack-stencil operation would be more important anyway. But what is really wanted is a primitive just giving out distance, and calling conventions that avoid a double calculation of each skyline pair when stacking things. https://codereview.appspot.com/13341044/diff/1/lily/stencil.cc File lily/stencil.cc (right): https://codereview.appspot.com/13341044/diff/1/lily/stencil.cc#newcode271 lily/stencil.cc:271: add_at_edge (a, d, s, padding, false); That's nonsensical. C++ knows defaults arguments for functions. https://codereview.appspot.com/13341044/diff/1/lily/stencil.cc#newcode313 lily/stencil.cc:313: offset = (*first_skyp)[d].distance ((*second_skyp)[-d]); This is an expensive non-cached operation, and yet this calculates skyline _pairs_ and ignores half of them. https://codereview.appspot.com/13341044/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): https://codereview.appspot.com/13341044/diff/1/scm/define-markup-commands.scm#newcode2038 scm/define-markup-commands.scm:2038: (ly:stencil-combine-at-edge m1 axis dir m2 0.0 #t))) Why use the same function in the first place when the last argument is never used as a variable? https://codereview.appspot.com/13341044/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
