RE: Dealing with nested properties.

[James Lowe]

Hello,

)-----Original Message-----
)From: address@hidden
)[mailto:address@hidden On
)Behalf Of David Kastrup
)Sent: 03 August 2011 11:08
)To: address@hidden
)Subject: Dealing with nested properties.
)
)
)What is the general feeling about override/revert with nested properties?

Oh yes please!

oh sorry... I mean

+1

)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.
)

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 :)

Else sorry for wasting your time.

James