Re: Checks for recursive element behavior (issue 6943072)

[Keith OHara]

On Sat, 22 Dec 2012 00:46:21 -0800, <address@hidden> 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, address@hidden <address@hidden> 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.