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

[lilypond]

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

Pushed into staging as
*   commit 2c1ffb66705c456712ad619a5296f080a7433756
|\  Merge: e328b7a 3c3bd54
| | Author: David Kastrup <address@hidden>
| | Date:   Fri Aug 22 07:17:50 2014 +0200
| |
| |     Merge branch 'issue3072' into HEAD
| |
| * commit 3c3bd54dcc1ad2c612625a95437b5a9fa10332b5
| | Author: David Kastrup <address@hidden>
| | Date:   Sat Aug 16 23:04:18 2014 +0200
| |
| |     input/regression/override-nest.ly needs matched \override/\revert
| |
| * commit 6d611627eaef3fb5c754bdde106cd16c1ed23f31
|/  Author: David Kastrup <address@hidden>
|   Date:   Thu Aug 14 22:20:35 2014 +0200
|
|       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.


Coverage with regtests is probably rather slim right now.  The  
documentation generally touches the previously unreliable nested overrides  
rather lightly.

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