Re: Overrides and nesting: intentional?

[David Kastrup]

James Lowe <address@hidden> writes:

 [...]

> )Now take that incoherent mess, and add nested properties into it.
> )Apparently the current code has no qualms to start an \override with a
> )pop that will cancel an entirely unrelated operation.
> )
> )Now if we do something like (never mind the value and the syntax)
> )\override a.b.c  \override a should the second \override be able to cancel
> )the first one with its implied \revert at its front?  How about if we do
> )\override a  \override a.b.c instead?  Should the second override be able
> )to cancel the first one?
> )Only partially?  What if we now do
> )\override a \override a.b.c \override a
> )How many \revert a should we need to have the stack empty again?  If
> )we do \override a \override a.b.c \revert a.b.c what should the state of
> )a.whatever be?  Changed against before or not?
> )What should the state of a.b.c be?  Changed against before (to the value
> )set by \override a) or not?
> )
>
> What do you think?

I started working on the nested property stuff by reverting a patch that
complicated the situation and introduced new illogical behavior while
making some test cases produce the expected results.

I have the impression that this is not dissimilar for straightforward
properties.  The "try to revert before override" behavior appears to me
like somebody considered it a good idea because it made something work
more similarly to what he/she expected, but resulting in behavior and
code that is harder to predict overall.

So I would like to hear _what_ the "revert before override" behavior was
supposed to be fixing.  Designing a useful behavior for working with
nested overrides is doomed to failure if I don't have a design of useful
behavior available for straightforward properties.

So I'd appreciate a case table of sequences of \once\override,
\override, \revert and their friends (\once\revert anybody?) together
with the _wanted_ outcomes and possible _acceptable_ outcomes.

> Seriously, that is not (meant to be) an impertinent question. You've
> obviously done a lot of thinking about this so why not lay your cards
> on the table and go from there. Take the lead.

Up to now I have just done code analysis, reading the behavior that is
currently there.  The user level documentation is partly in conflict
with what I read in the code.  Somebody obviously put that code there
for a _reason_.  It is more complex than the user level documentation.

There is no rationale to be found in the code.  So I'd like to hear it.
There is no point if I slash through the code, restore the simpler
behavior that likely was there at one time, and get the whole marked up
as a regression that gets re"fixed" in the same or analog manner.

I don't like the semantics of the current implementation.  I would tend
to tie overrides and reverts together on a lexical base (meaning you
can't revert things coming from a different music list or even the same
input source).  It seems particularly pointless to let \once\override
revert anything at the end of the time step that is unrelated to its own
override.

> I know the discussion is nice and all but it can all get a bit too
> philosophical - paralysis from analysis and all that, too much theory
> not enough practical.

I don't _have_ practical experience to offer.  I want to _fix_ stuff
that is being used, and that has obviously been complicated (and not
with uniquely positive results) by trying to accommodate practical
reasons.  This is why I am calling out here.  I can't accommodate the
same reasons if I don't get to know about them.

> If we're serious about changing/tidying this then why not make a
> proposal?  Then a real discussion can commence.

Fine.

Proposal 1: \override should not start with an internal \revert but
rather do just what the user documentation says: push its own version in
front of the existing alist of properties, without deleting existing
overrides.

Obviously, something considered bad will happen, or the code would not
go to the pains to do what it does now.  What is the bad thing that will
happen?

-- 
David Kastrup