GNU bug report logs - #22295
viper-mode undo bug introduced between Nov 10 and Nov 14

Previous Next

Full log

Message #22 received at 22295 <at> debbugs.gnu.org (full text, mbox):

From: phillip.lord <at> russet.org.uk (Phillip Lord)
To: Michael Kifer <kifer <at> cs.stonybrook.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22295 <at> debbugs.gnu.org, jim <at> meyering.net
Subject: Re: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov
 14
Date: Sat, 14 May 2016 21:39:34 +0100

Michael Kifer <kifer <at> cs.stonybrook.edu> writes:

> On 05/14/2016 09:57 AM, Phillip Lord wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> Date: Sat, 14 May 2016 12:25:13 +0300
>>>> From: Eli Zaretskii <eliz <at> gnu.org>
>>>> Cc: 22295 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
>>
>> Sorry for slow response -- was travelling.
>>
>> Yep, viper is doing strange things to undo -- it adds a symbol ('viper)
>> to the undo list, then removes it later, amalgamating everything upto
>> 'viper.
>
> I don't remember much myself, but the issue is this (and it is documented):

It's commented rather documented:-)

>
> In VI, the granularity of undoing is much coarser than in Emacs.
> Several ops that Emacs undoes in multiple steps are supposed to be
> undone with just one "undo" in VI. Viper simulates this by inserting
> viper-buffer-undo-list-mark onto buffer-undo-list to mark the point to
> which the Emacs undo's are to be run in order to accomplish one
> VI-style undo. In Emacs, as I vaguely remember, this role is played by
> nil(?), but VI-style undos are coarser than that, so viper requires
> its own marker on the unfo list.

Yes, you are correct -- boundaries are nil.

Viper puts it's own mark in, yes, but then deletes it later on and
replaces it with nil in this bit of code.


(setq tmp2 (cdr tmp)) ; the part after mark

;; cut tail from buffer-undo-list temporarily by direct
;; manipulation with pointers in buffer-undo-list
(setcdr tmp nil)

(setq buffer-undo-list (delq nil buffer-undo-list))
(setq buffer-undo-list
      (delq viper-buffer-undo-list-mark buffer-undo-list))
;; restore tail of buffer-undo-list
(setq buffer-undo-list (nconc buffer-undo-list tmp2)))

Essentially, it just kills the standard boundary handling and does it's
own thing.


> Hope this helps.

You don't by any chance remember why viper mode appears to turns itself
off in noninteractive mode? Turns out to be rather painful for testing.


> Sorry that I don't have much time these days to work on viper.  :-(

Too busy doing all logic and semantics?

Phil

Previous Next

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