On 9 mars 2013, at 09:51, d...@gnu.org wrote:
> On 2013/03/09 07:18:50, mike7 wrote:
>> On 8 mars 2013, at 14:10, mailto:d...@gnu.org wrote:
>
>> >
>> >
>
> https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly
>> > File input/regression/minimum-length-end-line.ly (right):
>> >
>> >
>
> https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly#newcode10
>> > input/regression/minimum-length-end-line.ly:10: \override
>> > TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
>> > 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.
>
The definition of "allow" in the New Oxford American Dictionary is "give the
necessary time or opportunity for." This patch gives spanners the opportunity
to have minimum length work at the end of the line.
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.
> 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.
If you do, please file an issue then to fix this as well as the following
snippets in the Documentation:
-)
http://lilypond.org/doc/v2.17/Documentation/notation/expressive-marks-as-lines#index-glissando-1
-) http://lilypond.org/doc/v2.17/Documentation/notation/spanners.html,
specifically "For some layout objects, the minimum-length property becomes
effective only if the set-spacing-rodsprocedure is called explicitly. To do
this, the springs-and-rods property should be set to
ly:spanner::set-spacing-rods. For example, the minimum length of a glissando
has no effect unless the springs-and-rodsproperty is set."
> So it is not clear that using this functionality would not
> break other things elsewhere.
>
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.
If the regtest is bothering you that much, I can just eliminate it from this
patch. It won't change the better functionality of this patch and will just
stop shedding light on the issue I'm discussing above. But that does not seem
like a good solution, nor does setting springs-and-rods with a default property.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
