Re: untangling the remaining regressions

[Keith OHara]

David Kastrup <dak <at> gnu.org> writes:

> > (1) The positioning of fingerings using the outline of the note-column
> > (the last patch under issue 2527) is a user-visible improvement, so it
> > would be nice to keep it.  I have posted patches to solve two issued
> > (3465 and 3363) were caused by the fingering patch, so maybe we can go
> > forward.
> 
> I've tried a revert recently, and the number and nature of revert
> conflicts, probably partly because of related followup fixes, was rather
> ugly.  This is entangled rather badly in our code history.  

Presumably you first reverted the follow-up patches, for issues 3327 
3242 and 3109.  If it is that complicated to retreat, it seems wiser
to fix the remaining bugs and go forward.

>
> > The fingering patch might also have made issue 601 worse, 

It did so.  I have separated the new part of the bug into issue 3497.

> > and possibly re-broken issue 40. 

No, that was the patch to tighten accidental placement, issue 2811.
Studying the original fix for issue 40 and the patch for 2811, might
make the proper solution clear.


> > (2) The expanded use of unpure-pure containers (issue 3199) is a
> > reorganization of the code.  Overall, I think the patch makes things
> > simpler, conceptually.
> 
> The problem is that the patch in question does dozens of different
> things in a single commit, a number of which are not even related to the
> issue.

Oh.  Well if the regressions were caused by any of the unrelated things
we can just reverse that part of the patch.

We do have a patch posted under issue 3385 that reverts 3199 entirely,
with a clean `make check`.

> > I think the remaining problems that it caused (issue 3385, issue 3359
> > and blocking the patch for issue 3363) come from its removal of the
> > test 'pure-relevant?', which ignored some objects for purposes of
> > estimating the heights of staves for the planning of
> > line/page-breaking (i.e., the pure-heights of VerticalAxisGroups).
> 
> But they should have been replaced by pure-unpure-containers.  

Well, the function-pairs that calculate/estimate the heights or 
positions of these object have been linked together into 
pure-unpure-containers.
Formerly, only objects with an explicit 'pure' (estimating) function
were considered 'pure-relevant' but in the new design everything is
pure-relevant.

Mike posted three patches to issue 3385 that attempted to go halfway
backwards, partially restoring the pure-relevant? test, but these
ran into regressions.

Going forward would be to make the pure versions of these functions, 
actually work properly before line-breaking, without triggering other
calculations prematurely (i.e., make them acually 'pure').
That approach looks like it might do some untangling, by solving
issued 3385 and 3363 together.

The remaining regression would be the erroneous cross-staff tie, 
issue 3395, which has always been an error but now crashes LilyPond.
For that, we should ensure in the code that the pure-Y-common (a.k.a.
common_refpoint_of array) of a set of objects used to find the height
of a staff, is the staff in question, because other code assert()s that
condition.