On Sat, 22 Dec 2012 00:46:21 -0800, <d...@gnu.org> wrote:
In this particular case, however, the problem is adding an axis group to an axis group. _Any_ old axis group to _any_ old axis group.
No no. The reported problem \new StaffGroup \RemoveEmptyStaves <<b1 b>> causes a StaffGrouper to be added to the VerticalAxisGroup created in the StaffGroup context. That by itself seems fine, as I would expect that StaffGrouper's elements to be the VAGs from the two grouped staves. For some reason, though, that StaffGrouper gets the VAG from the enclosing StaffGroup context added to its list. StaffGroups nest, which adds StaffGroupers to the elements of the outer StaffGroupers with no problem, so we are accustomed to letting grouping-objects have elements that are themselves objects of the same type. On Sat, 22 Dec 2012 02:01:25 -0800, m...@mikesolomon.org <m...@mikesolomon.org> wrote:
My patch is intended to avoid this segfault by not allowing recursive nesting of elements in theelements list.
Yes, but usually we look for the cause of a situation that triggers such an error-trap, when the situation itself seems incorrect. Does it not seem incorrect that the same VAG both contains and is an element of a StaffGrouper ? What correct processing of objects would make either of these inclusions ? Also, you still get segfault as soon as you add a second staff and complete at least one bar. (Try the example above as-is and substituting ChoirStaff.) If we use the Hara_kiri_engraver by default, and define removeEmptyStaves as \override VerticalAxisGroup #'remove-empty = ##t then it could be set at any level like the other options. I've just made this change on my Windows installation, and now my LilyPond works, and yours doesn't, nyah. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel