[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eliminates the Hara_kiri_engraver. (issue 7061062)
From: |
dak |
Subject: |
Re: Eliminates the Hara_kiri_engraver. (issue 7061062) |
Date: |
Fri, 25 Jan 2013 13:29:19 +0000 |
On 2013/01/25 13:02:39, mike7 wrote:
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.
The engraver created the grob in question itself, announced it itself
(so all acknowledgers have been called) and actually keeps a pointer
to that grob in itself.
It basically _owns_ that grob.
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.
What would happen?
Granted, this would also be bad after the engraver stage, but worse
in the engraver stage.
How so?
https://codereview.appspot.com/7061062/
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), (continued)
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), dak, 2013/01/14
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), dak, 2013/01/20
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), mtsolo, 2013/01/20
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), k-ohara5a5a, 2013/01/21
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), k-ohara5a5a, 2013/01/21
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), k-ohara5a5a, 2013/01/21
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), k-ohara5a5a, 2013/01/25
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), dak, 2013/01/25
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062),
dak <=
- Re: Eliminates the Hara_kiri_engraver. (issue 7061062), k-ohara5a5a, 2013/01/26