Thomas Morley <[email protected]> writes:
> 2018-08-02 23:02 GMT+02:00 David Kastrup <[email protected]>:
>
>> It is still being used, however, even though it has become impossible to
>> set it. More exactly, its hard-coded fallback value is being used.
>>
>> Should we stick with that and just drop the name of the property
>> altogether? It does not seem like it has been missed all that much...
>
>
> Regarding the recent discussion I'd vote to keep it as is for the time being.
>
>
> With the following minimal reimplementation it's settable again, so
> everyone interested may do experiments.
>
> #(set-object-property! 'skyline-quantizing 'backend-type? number?)
Sigh. It's still not part of any interface or of any grob description
and meddling with undocumented internals is not guaranteed to get the
results you desire.
In fact, with the changes I am working on the above will not do anything
and any attempt to use this will just blow up.
> %% after
> %% /input/regression/slur-vertical-skylines.ly
>
> \relative {
> \override Slur.skyline-quantizing = 100
> f'8^"rit"( c' f c' f) r8 r4 |
> c2( c,2 |
> g1)~\startTrillSpan
> g1\stopTrillSpan
> g1(\f
> g,1)
> }
>
> I suggest we wait for feedback and probably reimplement it in a saner
> manner with 2.21
I wasn't planning on cleaning up the (basically dead) affected code
parts for 2.20. But that does not mean that one can consider it a 2.20
"feature" that poking in some internals might cause this thing to
jiggle. It's more like a rotten easter egg.
It's not like I am intentionally looking for ways to annoy people: this
egg blew up in my face while working on significant performance
enhancements.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
