2011/8/3 David Kastrup <d...@gnu.org>:
>
> What is the general feeling about override/revert with nested
> properties? The current implementation for property list of grob
> properties maintains a data structure suitable for lazy updates of the
> spine of the grob property list.
>
> However, overrides for nested properties duplicate part of the _leaves_
> of property lists which then are not updated anymore. Since alists are
> not changed destructively, the update process for the spine of the
> alists also gets triggered for changes in the leaves, but its effects
> are restricted to updating the spine, so the copied environment of an
> overriding leaf is not updated. The resulting data structures can't
> distinguish
>
> \override whatever #'a #'the-current-default-alist-for-a-with-changed-elements
> and
> \override whatever #'(a b c) #'something-new
>
> But the first should disassociate the entire list for a from changes in
> parent contexts, while the second should merely disassociate a.b.c from
> changes in parent contexts.
>
> So there is no way that the current data structures will work
> consistently with the desired semantics. I see three ways of
> proceeding:
>
> a) Make things work as intended.
> b) Document that override/revert are just a rough approximation of the
> desired behavior, and make that approximation a good compromise between
> usefulness and simplicity, so that people can understand what will fail
> in what manner.
> c) Remove access to nested property as it does not work.
>
> I am currently working on angle a) but I am skeptical that it will
> result in code that is both efficient as well as easily
> understandable/maintainable. I find the current code already tough in
> that area.
I'm not sure if i understand this well enough, but in my opinion b) is
not an option. If you say that a) can result in code that is
difficult to use and maintain, i vote for c). However, it'd be great
if you could provide some specific examples so that i can understand
better. For example, is \override Stem #'details #'lengths = #'(3 4
4.5) (if i remember syntax correctly) related to this and how will it
be affected?
2011/8/3 James Lowe <james.l...@datacore.com>:
> 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))
> }
Interesting thing to discuss during GLISS.
cheers,
Janek
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
