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. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
