GNU bug report logs - #16411
undo-only bugs

Previous Next

Package: emacs;

Reported by: Barry OReilly <gundaetiapo <at> gmail.com>

Date: Fri, 10 Jan 2014 22:34:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Barry OReilly <gundaetiapo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 16411 <at> debbugs.gnu.org
Subject: bug#16411: undo-only bugs
Date: Sat, 11 Jan 2014 00:09:26 -0500
[Message part 1 (text/plain, inline)]
> I guess I do have some idea how to do it, but it looks like a lot of
> work, since we have to adjust the positions in the rest of
> pending-undo-list.

Are you saying the buffer positions in the undo data become
invalidated? That could indeed be a detail I missed. Let me take a
closer look.

> Right: the loop that undoes N steps (either in undo-more or in undo
> if we change undo to only call undo-more with a 1) needs not only to
> use undo-equiv-table at each iteration to skip redo entries, but it
> also needs to add an entry in undo-equiv-table at each iteration.

And recall that these N are rolled into one redo record. So a redo
record needs to reference N records it undid. That means
undo-equiv-table's value type has a new format that could conceivably
break user code, so let's name it something different:
redo-record-table. Now the only difference with redo-record-table as I
described it earlier is the off-by-one-change-group difference.

Actually, this makes me realize the solution to bug 1 is inadequate.
Calling (undo-primitive 1) N times creates N redo records whereas
(undo-primitive N) creates one.
[Message part 2 (text/html, inline)]

This bug report was last modified 10 years and 361 days ago.

Previous Next


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