Re: undo/redo

[John Kodis <kodis jagunet com>]

On Wed, Apr 22, 1998 at 12:11:26PM -0700, Seth Alves wrote:

> John Kodis:
> > My preferences, at least for text editors, are:
> >   = Fast, unlimited undo/redo, bound to auto-repeating keys.
> >   = When a file is saved, its edit history is discarded.
> >   = Saves happen w/o confirmation.  Exiting w/o saving modified
> >     buffers requires confirmation.
> 
> Why discard the history when the file is saved?

It provides a convenient way to commit a series of changes to a file
and to drop the history list.  While not the only way of working
(perhaps not even the best way), it does fit in well with the way that
most folks (or me, at least) think about the relationship between
files on disk and buffers in memory.

> Hello.  Is there any interest in a general undo/redo mechanism being
> in the gnome libraries?  Does anyone know of a nice interface for
> this, or existing GPLed implementations (in C)?

I think this would prove useful.  It'd look like a bi-directional
queue, but with the additional feature that it would get automatically
dribbled to disk periodically.  Additionally, methods to set a maximum
size or number of entries could be useful, and an advisory method to
note that entries before a certain point are expendable.

While I'm on the subject, let me point out a couple of differences
between the undo features of emacs and other editors that I've used.

Emacs provides undo, but to redo it's necessary to break the undo
sequence, then undo previous undos in order to achieve redo (got
that?).  I find the "undo/redo list as a time-line" view much more
intuitive -- undo moves to an earlier point in a file's history, and
redo moves to later points.

Emacs can undo the state of a buffer, but not the state of the editor
as a whole.  For example, if in emacs you kill a line and then undo
the kill, the line is reinserted in the buffer, but is left in the
kill ring.  The editor is in a different state than before.  There are
several problems with this.  It means that the undo history cannot be
used as a crash recovery mechanism.  It seems (again, to me at least)
less intuitive than restoring complete editor state.  It means that
only buffer-changing operations can be undone.  One of the things that
I most frequently used the undo mechanism for was to e.g., return to
somewhere in the middle of a file after a search operation or a jump
to one end of the file.  I find the pop-mark-ring command less
intuitive for this, even on those good days when I can remember what
key sequence it's bound to.

-- John Kodis.