lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stencil-integral: use box extents specified in markup; issue 3255 (i


From: Mike Solomon
Subject: Re: stencil-integral: use box extents specified in markup; issue 3255 (issue 9295044)
Date: Fri, 30 Aug 2013 10:55:09 +0200

On 30 août 2013, at 10:11, address@hidden wrote:

> On 2013/08/30 07:41:49, mike7 wrote:
> 
>> I'd still argue that (2) is the best way to go as it is a
> one-stop-shopping way
>> to clear all these bugs (and perhaps more) as they arise.
> 
> Since we are currently in the process of recovering from the last
> one-stop-shopping way to clear bugs galore which is where all those
> regressions are actually from,

The skyline code was not written to address bugs.  LilyPond's previous spacing 
algorithms weren't buggy - they were just less snug than they are now.

> I suggest that we refrain from
> embracing your somewhat optimistic estimates until after wrapping up a
> stable release.

I don't see the relationship between the two.  The skyline code was a major, 
over-a-thousand line overhaul of spacing.  This is much smaller in scale and 
addresses one specific aspect of the code.

I'm not claiming that any solution - Keith or mine - is bug proof, but rather 
that we should adopt the one that will get the most mileage against eventual 
spacing bugs with stencils.  The general category of problem we are trying to 
solve is "a shape around stencil X is not being represented in the skylines."  
My solution fixes problems in that general category, whereas Keith's addresses 
the more specific problem "a box around stencil X is not being represented in 
the skylines."

> 
> And frankly, I completely fail to see how this advertisement as a
> magic bullet for all the regressions is even remotely rooted in fact.
> The regressions will not in any way be automagically addressed by such
> sweeping changes.  The changes will offer different ways to address
> them and you like those better.  But that's not the same as actually
> getting them addressed.

We agree here.  In my previous e-mail, I make the case that this is a "way to 
clear all these bugs" and above you correctly identify that it offers "ways to 
address them."  I don't think it's a magic bullet, but rather a general 
framework that allows us to address this category of bugs without coming up 
with specific solutions for each bug.

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]