https://codereview.appspot.com/13582046/diff/1/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (right):
https://codereview.appspot.com/13582046/diff/1/lily/tuplet-bracket.cc#newcode99
lily/tuplet-bracket.cc:99: if (!left || !right)
Too many combinatorics involved unnecessarily. Just do
if
On 13 sept. 2013, at 08:41, d...@gnu.org wrote:
https://codereview.appspot.com/13582046/diff/1/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (right):
https://codereview.appspot.com/13582046/diff/1/lily/tuplet-bracket.cc#newcode99
lily/tuplet-bracket.cc:99: if (!left || !right)
Too
On 2013/09/13 07:09:44, mike7 wrote:
With respect to your point about null pointers and the nature of the
patch, I
agree that there needs to be a better way to handle this. To me, the
general
problem seems to be what do we do when we assume a grob will have
something
(bound, object,
On 2013/09/13 08:41:42, Trevor Daniels wrote:
On 2013/09/13 07:09:44, mike7 wrote:
With respect to your point about null pointers and the nature of the
patch, I
agree that there needs to be a better way to handle this. To me,
the general
problem seems to be what do we do when we
On 13 sept. 2013, at 11:00, d...@gnu.org wrote:
On 2013/09/13 08:41:42, Trevor Daniels wrote:
On 2013/09/13 07:09:44, mike7 wrote:
With respect to your point about null pointers and the nature of the
patch, I
agree that there needs to be a better way to handle this. To me,
the general
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
