Once again i'm reviving an old thread, but since i was involved in discussions with David before i disappeared, i'd like to give my feedback on this.
2011/8/14 David Kastrup <[email protected]>: > there are the proposed semantics. At least for the > latter, I would want to get some sort of feedback. > > The semantics can be summarized as follows: > > a) a revert will only cancel the last _matching_ override, and the match > includes the complete specified property path, _and_ the prospective > use of \once. \revert will not cancel \once\override and vice versa. > b) At the end of a timestep, all \once\override are reverted. All > non-\once overrides remain in effect and on the stack as if none of > the \once\override had ever happened. 2011/8/14 David Kastrup <[email protected]>: > There are likely two contentious changes. The first is related to > nested properties: namely that the pairing of override/revert of a > property x should be independent from override/revert of a nested > property x.y. However, if overrides and reverts of x and x.y are not > acting as if they were issued independently, and if overrides and > reverts of x and x.z are not acting as if issued independently, then it > gets quite hard to let overrides and reverts of x.y and x.z act as if > they were issued independently. And that would make working with nested > properties less straightforward in my opinion. > > The second is that \once\override will not mix with \override\revert. > Currently \once\override ... \override will have the second \override > active just for the current timestep, and revert to the previous value > afterwards. \override ... \once \override ... \revert \revert will at > first revert both overrides, but reinstate the state after the first > override at the end of the timestep. If I understand the code > correctly. LGTM. (sorry that i don't have anything more constructive to say) thanks for your work, David! Janek _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
