lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nested context properties -- an implementation sketch


From: Janek Warchoł
Subject: Re: Nested context properties -- an implementation sketch
Date: Tue, 23 Aug 2011 23:11:38 +0200

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 <address@hidden>:
> 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 <address@hidden>:
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]