Re: [Lilypond-auto] Issue 3072 in lilypond: Nested overrides get confused with multiple contexts in play

[lilypond]

Updates:
        Labels: Patch-new

Comment #2 on issue 3072 by address@hidden: Nested overrides get confused with  
multiple contexts in play
http://code.google.com/p/lilypond/issues/detail?id=3072#c2

Issue 3072: Nested overrides get confused with multiple contexts in play

The main problem with nested overrides lies not as much with the
override (which can be done reasonably well) but rather with the
corresponding reverts.  Detecting and undoing a previously established
nested override by its effects on an alist, particularly when nested
overrides may be present at several different levels in several
different contexts and/or stack depths and may be undone in different
order from being established, is a complex problem.  It is complex
enough that it is not clear that a satisfactory solution does even
exist: at least LilyPond's implementation breaks down for a number of
test cases.

The approach of this implementation is to not even try reverting nested
overrides from looking at their effects on the final result.  Instead
nested overrides like

\override Staff.TextSpanner.bound-details.left.text = #"foo"

are not done by creating an assembled alist element for TextSpanner
looking like

(bound-details . ((left . ((text . "foo") ...)) ...))

with ... filled in from other parts of the alist (which may change
independently at a later point of time) but rather by using
(bound-details left text) itself as a key and thus storing

((bound-details left text) . "foo")

as the representation of the override.  Consequently, reverting an
override with the same nested property path is straightforward.  Neither
the action of overriding nor of reverting now require referring to or
updating any part of the property stack outside of the current context.

The downside is that an actual reference to the resulting grob alist
requires expanding the nested overrides at the time of creating a grob
or otherwise asking for ly:context-grob-properties.

Since issue 2507 encapsulated grob property access into the
Grob_property_info algorithm container structure relying on data stored
in context properties of elements of type Grob_properties, changing the
respective algorithms can be facilitated completely in those classes.

In order to provide similarly efficient access and reasonable caching
and just-in-time reevaluation of previously computed values,
Grob_properties needed to be significantly extended in size.

http://codereview.appspot.com/131770043

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings