Re: Dealing with nested properties.

[Jan Warchoł]

2011/8/3 David Kastrup <address@hidden>:
>
> 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 <address@hidden>:
> 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