Comment #9 on issue 1063 by d...@gnu.org: Reverting nested property fails to restore default value if preceded by override in same grob
http://code.google.com/p/lilypond/issues/detail?id=1063
Figure me annoyed. When a nested property is being set, all the subpaths leading to it are copied from the context carrying the top property of the nesting, and an augmented subpath is prepended. Any property lookup for any subpath of the top property will now happen through that copy.
Regardless of whether subproperties in parenting contexts get modified. At the time that the whole tribe is copied, the relation to the originals gets lost. With the current data structures, subproperties can't be overridden and reverted as if they were independent from other properties of their tribe (in the same hierarchy).
This is nothing one can fix by doctoring revert. The whole concept is broken if I understand this correctly.
Can somebody give me an overview about what nested properties we currently have, and how they are accessed? Are any parent properties accessed with the expectation that a useful alist pops out? Or could we use different data structures for the parent properties in a hierarchy?
_______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond