Re: Ev2 as a move-aware editor

Daniel Shahaf <danielsh_at_elego.de> writes:

> My own answer to "how to change Ev2 to enable representing rotate(A,A/B/C)":
>
> I think the above means we have to modify move() to use SRC arguments
> relative to the start state of the edited tree, rather than to its
> current state.

> If we do that, we could represent your commit as:
> mv(A/B/C, A); mv(A/B, A/B); mv(A, A/B/C);.
>
> While we're making changes, I wonder if we should nuke rotate(). I have
> several reasons:

I've been thinking of that as well. rotate was not it the first draft
of Ev2, it was added when I asked how to order the moves in a swap.

You have ordered these "start state" moves by depth order of the
destination, which seems reasonable. I think that implies that the
destination refers to the current state which is the same as the final
state.

So the pair

   mv(A, B) ; mv(X, B/Y)

has to be in that order while the pair

   mv(A/P, A/Q) ; mv(B/S, B/T)

could be in any order.

The two moves that make up a swap:

   mv(A, B) ; mv(B, A)

or

   mv(A/X, B/C/Y) ; mv(B/C/Y, A/X)

can usually be in any order (except for the unusual case such as A/B/C
above).

For a swap/rotate the receiver is responsible for doing something to
enable the moves to occur. I suppose different receivers could do
different things. The driver knows when mv(A,B) is part of a rotate and
when it is just a move. Perhaps it should distinguish the two and
communicate this so the receiver knows as well?

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com