James Lowe <james.l...@datacore.com> writes:
> You already know that I am not capable of giving you the technical
> answer you want, but as a 'joe user' having to list a dozen individual
> overrides in my layout block or within the music itself is very
> tedious.
> But taking a specific and easy to get, example, I have in one score
> the following in my \new Staff { } construct:
>
> \override MultiMeasureRest #'expand-limit = #8
> \override MultiMeasureRest #'minimum-length = #10
> \override Score.OttavaBracket #'dash-fraction = #0.15
> \override TextSpanner #'(font-name) = "Baskerville"
> \override TextSpanner #'(font-size) = #0
>
> Not that huge but it would be great to just be able to write
>
> \override {
> MultiMeasureRest #'expand-limit = #8 #'minimum-length = #10
> Score.OttavaBracket #'dash-fraction = #0.15
> TextSpanner #'(font-name) = "Baskerville" #'(font-size) = #0
> }
>
> Or perhaps
>
> \override {
> MultiMeasureRest (#'expand-limit = #8) (#'minimum-length = #10)
> Score.OttavaBracket (#'dash-fraction = #0.15)
> TextSpanner (#'(font-name) = "Baskerville") (#'(font-size) = #0)
> }
>
> Or can we list within lists?
>
> \override {
> MultiMeasureRest #'((expand-limit, 8) (minimum-length, 10))
> Score.OttavaBracket #'(dash-fraction, 0.15)
> TextSpanner #'((font-name, "Baskerville") (font-size, 0))
> }
> Please tell me that was what you were thinking of :)
Uh no. That would be about half a dozen of feature request. I was
concerned with making the already existing features actually work, or
else make them fail in a way that people can understand.
The current approach (I reverted the respective commit recently) to "bug
fixing" nested property overrides was a whack-a-mole game: see
inconsistent behavior, create a regtest for it, add some code that makes
this particular regtest work, get new inconsistent behavior, repeat
until the code is so complicated until nobody dares touching it anymore.
Since the used data structures can't differentiate between cases that
need to be distinguished for getting correct behavior for different
cases, this leads nowhere.
> Else sorry for wasting your time.
You can still put a feature request on the tracker, but don't get your
hopes too high. But since your request would be more or less just
supporting different syntax rather than semantics, it would have
independent hope of getting served or discussed, even if this ends up as
"waiting for GLISS".
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
