Re: \once \revert

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 8/21/11 3:01 AM, "David Kastrup" <address@hidden> wrote:
>
> \override -- pushes a value on the stack to remain until reverted
> \once \override -- pushes a value on the stack to last only for this time
> step.  Should be marked as special since it is a \once
> \revert -- pulls a non-once value from the stack.
> \once \revert -- pulls a non-once value from the stack, but the pull will
> last only for this time step.  Because there's no way to keep the pull on
> the stack, this would require something like a separate once stack.

Separate once stack is making me nervous.

> \revert \once -- pulls a once value from the stack.  Lasts only for the
> current time step (as does the corresponding \once \override that is
> pulled).
>
> I think these semantics are clearly explainable and are close to the current
> performance, IIUC.  The changes are that \revert and \once \revert ignore
> \once \override, and \revert \once is added to allow the reversion of a
> \once \override.
>
> Note that I still have a hard time seeing a reasonable use of \revert \once.
> It's only valuable if you know that you already have a \once \override on
> the stack.

_And_ if you have no clue what the original value might have been,
otherwise you could just issue another \once\override since both
overrides will cancel anyway at the end of the time step.

Basically, this is if you use some macro/music function which does a
\once\override as part of its operation, and you don't want that
override to occur.

Part of the design complexity here is that overrides are maintained
principally in the final alist used as property list for a grob, and
there are only sparse auxiliary structures (actually, I am working on
them right now for the once/nested info) keeping some additional
information.

It may be smarter to put all overrides in a separate source data
structure/stack, and assemble the final alist from scratch when it is
needed.  One advantage would be that one could omit overrides (and
nested overrides) that are completely masked by later overrides in the
same context, making the final alist shorter and lookups faster.

However, for things like nested overrides, parts of the subordinate
alist need to be consulted anyway.  So I prefer going through with the
current design.

Anyway, those discussions cost too much time and energy right now, and I
have several other commitments coming up, so I try getting something
finished soon.

-- 
David Kastrup