Re: Version Compare/Merge: Remaining Issues

[Michael McClary <michael>]

> NESTED MOVEMENT
> 
> [Problems selecting a movement by clicking on text that has
>  participated in more than one movement]

How are you displaying the movements?  If you have symbols for
them, something like this: \---v---/         ^ clicking on the
                               +------>------^
symbol for the motion, rather than the object moved, is
unambiguous.

> VCOPIES
> 
> [Confusion between insertion/deletion and move, how to pair
>  multiple vcopies,]
> 
> TRUE DEFICIENCIES
> 
> [Cases where this algorithm gives less-than-dandy results]

Hmmm...  Seems to me the whole point of displaying a version compare
is to come up with a plausible editing-history for the document, when
that information is not available, or not sufficiently fine-grained.
We must, of course, have this.

Nevertheless (at the risk of crossing the complexity of the existing
can of worms with that of another)...

 - Have you looked at what could be done with using intermediate states
   of the document's editing history as a hint to your algorithm (or
   having it ask the backend for a little history when things get hairy)?

 - Similarly, have you compared the problems of displaying version compare
   and displaying history?

> Though there is a warm place in my heart 
> for the alpha-beta minimax algorithm needed to do this 
> efficiently, I do not believe it is worth the effort 
> for Release 1.

Weren't you the one that pointed out an instance where a flaw in
a tree-pruning minimax algorithm went undiscovered into a release
because it worked, though slowly, with early rejection broken?
That's a testing problem, too.

I'd prefer it if algorithms that will produce correct results
despite major bugs were carefully identified for extra testing,
and avoided where practical in first-release (or left switched-
to-dumb until the overall system is working well enough to
provide a testing platform.)

	michael