On 2013/03/10 00:32:43, mike7 wrote:
>> > Why is this override needed for the regtest? The other overrides > are >> > obvious user-accessible overrides for triggering the tested >> > functionality. >> > >> > But should _this_ override not be the default? >> > >> > https://codereview.appspot.com/7453046/ > >> Perhaps open a tracker issue for this? >> The question is not only valid for text spanners but also hairpins, > glissandos, >> etc. > > Last time I looked, this issue purportedly "Allows minimum-length to > work for end-of-line spanners." And according to the regtest, it
does
> not do the job. Without additional messing with springs-and-rods it > does not allow minimum-length to work for end-of-line-spanners. >
[...]
Additional messing with springs and rods is because minimum-length is currently implemented by four different interfaces (lyric-hyphen, multi-measure-rest, ottava-bracket and spanner) and is also looked up in lyric-extender in a way that does not correspond to its docstring. So, certain uses of minimum length require the additional override whereas others don't. I do not think this is ideal, which is why I proposed a few weeks ago standardizing property names across interfaces. It seems like the issues you are raising above and below have less to do with this patch and more to do with the multiple implementation of minimum-length and the use of the springs-and-rods property.
This is a typical case of "Somebody Else's Problem". If there is a party and you place a chair in the worst possible place, like somewhere in a doorway, people will walk around it, squeeze themselves through, get annoyed again and again. That's our current state. Now someone wants to do a polonaise and since the chair is in the way, he proposes putting a plank across it. Now we are moving from ridiculous to absurd, and it becomes harder to do the right thing. Yes, I am fully aware that you are not responsible for the chair in the way of your polonaise. Bit it is time to move it aside rather than taking it into account in our planning and make it even harder to get into a proper state. In particular since your coding style requires a lot of reverse engineering in order to figure out the hidden assumptions and dependencies. So that makes it doubly desirable to not add further dependencies on broken behavior but first clean up the foundations. Yes, that's not a problem caused by your patch, but the consequences are acerbated by it.
> The only thing more frustrating than missing functionality is > purportedly available functionality that needs > non-user-comprehensible trickery to actually work.
I do not have a problem with the current need to set the springs-and-rods separately.
Of course you don't, and nobody keeps you from applying this sort of patch to your own private code base without doing the necessary cleanup before. But you are not the metric for what goes into LilyPond's own repository and what not. The functionality that goes into LilyPond has to work for the average user encountering that problem space. The solutions have to have a meaningful correspondence in complexity to the problem and not require "don't think about it" steps.
I'm positive it would because of the way that minimum-length is multiply defined. That is why this patch is intended for the "some layout objects" discussed above like the TextSpanner. I agree that the multiple use of the minimum-length property should be changed, but this seems like the business of another patch.
Sure. But that patch will be harder to do once this patch _relies_ on the broken behavior, and people write code _relying_ on this patch.
If the regtest is bothering you that much, I can just eliminate it from this patch.
There is no point in hiding the symptoms of a problem away. That only makes things even harder in future. https://codereview.appspot.com/7453046/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
