The point is to allow users to achieve the same snug skyline spacing between stencils that is achieved between grobs.
I agree that it is inefficient as skylines are never cached, but as it is not default beahvior anywhere in the code base, it allows people to decide on the efficiency versus snugness-of-placement trade-off. For people creating complex markups, this is useful. 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); On 2013/08/28 21:17:20, dak wrote:
That's nonsensical. C++ knows defaults arguments for functions.
Done. https://codereview.appspot.com/13341044/diff/1/lily/stencil.cc#newcode313 lily/stencil.cc:313: offset = (*first_skyp)[d].distance ((*second_skyp)[-d]); On 2013/08/28 21:17:20, dak wrote:
This is an expensive non-cached operation, and yet this calculates
skyline
_pairs_ and ignores half of them.
Made a Skyline-only function. 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))) On 2013/08/28 21:17:20, dak wrote:
Why use the same function in the first place when the last argument is
never
used as a variable?
What would be a better way to achieve this? https://codereview.appspot.com/13341044/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
