GNU bug report logs - #16411
undo-only bugs

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Barry OReilly <gundaetiapo <at> gmail.com>
Cc: 16411 <16411 <at> debbugs.gnu.org>
Subject: bug#16411: undo-only bugs
Date: Wed, 14 May 2014 14:45:43 -0400

> Item 1 is the crucial one. The undo-redo-table is somewhat like
> undo-equiv-table, except that instead of mapping equal buffer states,
> it maps undo elements to what they undid.

I'm having trouble understanding it (I guess it's just that my mind
i caught in a rut, after having come up with undo-equiv-table).

> +(defvar undo-redo-table (make-hash-table :test 'eq :weakness t)
> +  "Hash table mapping undo elements created by an undo command to
> +the undo element they undid.  Specifically, the keys and values
> +are eq to cons of buffer-undo-list.  The hash table is weak so as
> +truncated undo elements can be garbage collected.")

[ Nitpick: the first line of the docstring should stand on its own.  ]
You talk here about "undo element", but AFAICT this actually points to
"a list of undo elements" (where the first element of that list is
presumably the "undo element" you mean).  Please clarify.

It's hard for me to really understand how this undo-redo-table would work
without seeing it in use.

My guess is that the "undo-only" case would skip redo entries in much
the same way as undo-in-region skips "out of bounds" entries (i.e. in
a fairly expensive way, adjusting all subsequent elements).
Combined with the fact that undo-redo-table contains entries for every
redo element rather than for every redo group, I'm slightly worried
about the resource use, but I guess that since undo-in-region is fast
enough, that won't be a problem.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.