https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly File input/regression/minimum-length-after-break.ly (right):
https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly#newcode15 input/regression/minimum-length-after-break.ly:15: \override Tie.minimum-length-after-break = 20 On 2015/02/05 23:34:22, thomasmorley651 wrote:
On 2015/02/05 22:51:06, david.nalesnik wrote: > On 2015/02/05 22:31:33, thomasmorley651 wrote: > > I'd use \once \override ... > > Though, that's only me > > I'm happy to change that. Would you use \once with the other
overrides in the
> file?
I'd always use \once. But again, it's only me, what do others think?
I went ahead and changed to \once. The object being overridden changes, and the Scheme music representation isn't any shorter, but \once might prevent problems should the test be extended. (Done.) https://codereview.appspot.com/201140043/diff/1/input/regression/minimum-length-after-break.ly#newcode16 input/regression/minimum-length-after-break.ly:16: a1~ On 2015/02/05 23:34:22, thomasmorley651 wrote:
On 2015/02/05 22:51:06, david.nalesnik wrote: > On 2015/02/05 22:31:34, thomasmorley651 wrote: > > I assume it works for chords as well. > > I'd add at least one example with chords and Tie or Glissando > > Instead of the one regtest, I could have two. > > The first would show a tied chord, and I would show how you can use > 'minimum-length and 'minimum-length-after-break in various
combinations.
> > The second would be this regtest, and I could take out the tie
example so
> there's no overlap with the other test. > > What do you think?
I can't see an advantage in having two regtests. I'd prefer to extend
this one. After discovering an issue (corrected in patch set #2), I'm leaning towards a regtest specifically aimed at showing how minimum-distance and minimum-distance-after-break relate. They ought to produce the same results in the spanner piece after the break. The C++ code uses these values in a way that is not easy to understand, and I think there should be a check for future changes to the springs-and-rods callback. https://codereview.appspot.com/201140043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
