On 8/19/11 2:57 PM, "David Kastrup" <d...@gnu.org> wrote: > Carl Sorensen <c_soren...@byu.edu> writes: > >> On 8/19/11 10:15 AM, "David Kastrup" <d...@gnu.org> wrote: >>> >>> Up to now, \once \revert is not really documented nor used. I have not >>> yet dug through the existing code in order to figure out what it does if >>> anything (most likely ignoring \once, but not sure). >> >> I would expect that \once \revert would revert an \override for the >> current time step only (meaning events whose start time is the current >> moment). For any events whose start time is other than the current >> moment, the \override would continue to apply. >>> >>> In order to not have the override/revert stack get into unexpected >>> interactions, I want to change \once\override to be impervious to >>> normal reverts. >> >> This seems to me to be a wise decision. \once \override is a >> statement that you are creating an override for everything happening >> at the current moment; reverts would not seem to apply. > > The main problem is that \once\override comes with its own implicit > revert at the end of the time step, and when this implicit revert > applies to a different \override, things get surprising. If this > implicit revert is made special so that it will only ever apply to its > corresponding \override, then having other \reverts match the > \once\override will seem surprising.
Let me see if I can state your concern with an example. \override x = 1 \once \override x = 2 \override x = 3 At the current time step, you want to have x = 3, because of the last-encountered override. Then at the next time step, you want to have x = 3, because of the last encountered override. But if the \once \override x = 2 is canceled by an implicit revert, there is the potential to have x = 1 at the next time step, which is a counterintuitive and therefore wrong result. I can see that this is not a desirable outcome. My thought for the architecture is to have two sets of properties -- the context set and the \once set. Let me explain my thought. Before any of these commands is issued, the context property set has x = 4. The \once set is empty, because there has been no \once issued at this time. when \override x = 1 is received, the context set gets an x=1 prepended (and put on the stack, I suppose -- I'm not sure exactly how this is implemented as a stack). When \once \override x=2 is received, the context set gets copied to the \once set, because we want to base the \once set on the current context set. Then x=2 is put on the \once set, but not on the context set. When \override x=3 is received, it's put on both the \once set and the context set. When it's time to get a property, since the \once set is not null, we get the value from the \once set. At the next time step, we set the \once set back to null, because there are no \once overrides. We don't need an implicit revert; we just forget the \once set. This comes at the price of carrying a second set of context properties when we have a \once. But that happens very rarely. So really, we have the cost of carrying an empty list around. Under this architecture, \once means "if the \once set is empty, copy it from the current context properties" \override means "apply the override to the context set. If the \once set is not empty, also apply it to the \once set". \revert means "apply the revert to the context set. If the \once set is not empty, also apply it to the \once set." With this architecture, I don't think there are any surprises. > >> I have no idea whether there is a sensible use, either, but it is >> logically consistent, IMO. > > It is also logically consistent to let the prefix \once make the > following operation work on the set of \once overrides, as opposed to > the set of not-\once overrides. And the sets differ by having the \once > overrides be autocleared at the end of the timestep. As described above, I'd have \once work on the \once overrides, but I'd have not-\once work on both sets. Thanks for listening. Carl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
