Re: Redo/Undo (was: etags: M-. jump to the tag(called func), ...)

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

[A complimentary Cc of this posting was sent to
David Kastrup 
<dak@gnu.org>], who wrote in article <85mzm8rwer.fsf@lola.goethe.zz>:
> > [A complimentary Cc of this posting was sent to
> > B. Smith
> > <bpsm@aon.at>], who wrote in article
> > <mailman.7386.1127026972.20277.help-gnu-emacs@gnu.org>:
> 
> Your practice of "complimentary copies" is a pain in the ass, in
> particular when sent from a spam-address.  There is no reason for you
> to assume that people replying to you on a mailing list do not
> actually read the mailing list.

  a) What makes you think it is a spam-address?

  b) What makes you think I send it to a mailing list?

If you actually read the headers, you can see that your assumptions
are both wrong.

> > With redo you can do the following (and I do it all the time):
> >
> >   a) go back in time;
> >
> >   b) Maybe I overshoot?  go forward in time a little bit.  No I did not;
> >
> >   c) So I go back in time some more.
> >
> >   d) Jump to b.
> 
> There is no clear notion about when to abandon history, and which
> parts of "going back in time" are actually intended as a forward
> change.

Of course there is.  If you want to keep the maximum amount of state,
and allow "linear access" to all these states, then "redoing an undo"
should not add states to undo stack, but remove them:

 Current logic of having the stack of states after doing undo,
 overshooting and redoing, then editing:

  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\
								    |
               /<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<</
               |
	       \>>>>>>>>>>|
			  | new branch
			  |
			  |>>>>>>>>>>>>>>>>>>>>>>


 This has the same set of stored states, but avoids the "exponential
 growth" effect:

  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\
								    |
                   B -->  /<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<</
			  | new branch
			  |
			  |>>>>>>>>>>>>>>>>>>>>>>


One can also keep the information about what are branch points (like B
above), and let the users choose what they want to do at point B when
they start to undo the whole diagram above: they may want either

  a) go to the right branch, where they would effective "redo the dead
     end";

  b) go directly to the left branch (which is similar to what the
     other editors with undo/redo functionality do - they forget about
     dead ends).

> If you want to ignore this, there is redo.el

Is it in the distribution now?

Thanks,
Ilya