On 13 août 2013, at 11:33, "Keith OHara" <k-ohara5...@oco.net> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel