The first two patches look good. Defensive checks for null pointers are a good thing. We do not want a bracket for the input in the bug-report. We want a message when our .ly input asks for a tuplet bracket that cannot be printed, and we get such a message (just before a crash, without this patch).
Maybe "warning" would be more appropriate than "programming error" as the message in tuplet-engraver.cc, since LilyPond allows both the input in the bug report and this variant where we want, and get, a bracket: \new Voice << { %%% \once\override Voice.TupletBracket #'cross-staff = ##f \times 2/3 { s8 s8 s8 } r2. } { b8*2/3 b b } >> If there are no bounds to attach the bracket to, it would make sense to skip the creation of the TupletBracket with a continue; statement after the error message in tuplet-engraver.cc https://codereview.appspot.com/13582046/diff/11001/lily/tuplet-bracket.cc File lily/tuplet-bracket.cc (right): https://codereview.appspot.com/13582046/diff/11001/lily/tuplet-bracket.cc#newcode809 lily/tuplet-bracket.cc:809: Why check the bounds here? We certainly don't want to check break_status_dir() here. Conceptually, the (line-broken) tuplet /could/ end on a line-break, but still be cross-staff. In fact, the first time cross-staff is called is now before line-breaking, so break_status_dir() is 0, and the value of cross-staff is stored in the property so it need not be called again. Now that there is no more pure-relevant filter, adjacent_pure_heights() should probably use the get_pure_property() method of checking cross-staff, omitting object for which cross-staff is true or non-boolean (a.k.a. "don't know yet"). https://codereview.appspot.com/13582046/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel