lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eliminates the Hara_kiri_engraver. (issue 7061062)


From: address@hidden
Subject: Re: Eliminates the Hara_kiri_engraver. (issue 7061062)
Date: Fri, 25 Jan 2013 14:02:31 +0100

On 25 janv. 2013, at 10:29, address@hidden wrote:

> On 2013/01/25 08:05:28, Keith wrote:
> 
> https://codereview.appspot.com/7061062/diff/9001/lily/axis-group-engraver.cc
>> File lily/axis-group-engraver.cc (right):
> 
> 
> https://codereview.appspot.com/7061062/diff/9001/lily/axis-group-engraver.cc#newcode120
>> lily/axis-group-engraver.cc:120: // mess everything up...but at least
> this
>> avoids a duplicate context
>> Please demonstrate a sneaky callback messing things up.
> 
> Since sneaky callbacks can mess a lot of things up, a comment like that
> would likely be only warranted if "sneaky callback" can cause conditions
> that lead to programming errors, and possibly even just crashes.

To be fair, the callback in question would be no sneakier than your average 
sneaky callback.  In general, reading grob properties in the engraver stage is 
a bad idea. I am guilty of writing code that does this, but that was before I 
saw the light.  Something to the effect of:

\override Staff.VerticalAxisGroup #'remove-empty = #(lambda (grob) 
(iterate-through-all-elements-and-get-Y-extent grob))

would do the trick.  Granted, this would also be bad after the engraver stage, 
but worse in the engraver stage.

However, as I said above, this type of thing can be done at other places in the 
code too, so perhaps it is worth it to take out the comment.

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]