> Hi everybody,
>
> I've been considering the following thought experiment for undo/redo:
>
> 1. Doc state = A
> 2. Op A is performed by Mandy, Doc state = B
> 3. Op B is performed by Fred, Doc state = C
> 4. Mandy hits undo on her local editor
> 5. Doc state = ??
>
> What does Mandy expect to have happen? Does this undo Op A or Op B?

Another option would be to just have Undo to be another new operation which
just is the invert of the op that should be undone. Which means the original [...]

You just missed my proposal mere paragraphs away that suggests the same thing :)

[...]
It might be also possible to undo any op in the stack (given the inverted op
can be transformed through the rest of the op stack). So the UI could offer to
just undo your own last ops, or undo ops/actions from everyone.

Correct. This should also be possible (though, how desirable? I'm unsure)

Would also mean no need for the complexity of a dedicated undo/redo manager.

I disagree. You will still (always) require a dedicated undo-redo manager. For example,
in LibreOffice (and many editors), typing consecutive letters without changing the
cursor position in between is undone as a single block. This grouping happens after

each individual operation is fired away. (If you look at the current undo manager it
is actually rather straightforward... not as much complexity in there as you fear
I assure you! :) )

Of course this requires that all info needed to invert an operation is still
available, like the properties of removed styles, overwritten style
properties, removed text, etc. Which means quite some changes to our current
opspecs and op creation code, but this should not stop us, at least in the
long run.

This is the main reason I was raising this. Rather than having the undo op

be immediately available when the original op is created, it will likely be easier
to literally generate the undo op *whilst* applying the original. This means less
traffic for everyone, and (theoretically) allows all the benefits one would expect
from an undo stack.

In any case we should see to keep clients ODTs as convergent as possible,
ideally 100 %. Anything else might only mean troubles later and hard to
reproduce errors, my gut tells.

Correct. I agree with this fully! But, nowhere have you said that undo needs to

result in exactly the same document as before the (now undo) operation was
performed. So... is it safe to say that "visually identical" is acceptable,
even if the document is "changed"? :)

---
Philip Peitsch
Mob: 0439 810 260