Re: untangling the remaining regressions

[David Kastrup]

"Keith OHara" <address@hidden> writes:

> When solving regressions we have the choice to go forward or to retreat --
> to repair, or revert, the change that caused the regression.
>
> (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.  Of course, a
lack of structural modularity (modularity is not splitting a function
doing one job into two or more intertwined parts, but reining in
functional domains of interaction into groups.  Code apartheid) does not
particularly help with that.

> The fingering patch might also have made issue 601 worse, and possibly
> re-broken issue 40.  I hope one of use can bisect to isolate the cause
> of these.

Sigh.

> (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.

> 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.  Except
that it does not seem that this has been verified for each such function
and its data structures like, say, laissez-vibrer ties.

> When we have objects that cross staves, and we include them in the
> pure-height of one of the staves, that height depends on page-layout,
> which we have not yet determined.
>
> So we can revert 3199 with no loss except going back to the old
> more-complex code, or try to repair, probably by reimplementing a
> filter to do some of what 'pure-relevant?' used to do.  (My thinking
> now is that for a Grob to be pure-relevant to a Staff, it must have
> that Staff as a (grand*)-parent.)
>
> Does anyone see reason to try to move forward, to repair the
> unpure-pure-containers patch (3199) ?

If we can reasonably cleanly revert it, that would be an option.  We
arrive at code that has not seen testing in the context of our other
current code base, but it's not like "moving forward" would be much
better in that respect.

-- 
David Kastrup