Re: untangling the remaining regressions

[Mike Solomon]

On 13 août 2013, at 11:33, "Keith OHara" <address@hidden> wrote:

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


The short term solution may be to create an internal property called 
"pure-relevant", set it to #t as default for all grobs in the Grob::Grob 
constructor and set to false only when necessary in define-grobs.cc.  Then, 
write a big fat comment saying that the goal eventually is to remove this test 
and make sure to say that the property is _strictly_ internal.

This is more elegant than the Scheme functions in the old implementation but 
less elegant than the currently (albeit broken) solution of removing the 
pure-relevant distinction.

I can do this tonight - does this sound like a reasonable middle-ground 
solution?

Cheers,
MS