[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14

From: Michael Kifer
Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14
Date: Sat, 14 May 2016 16:50:07 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 05/14/2016 04:39 PM, Phillip Lord wrote:
Michael Kifer <address@hidden> writes:

On 05/14/2016 09:57 AM, Phillip Lord wrote:
Eli Zaretskii <address@hidden> writes:

Date: Sat, 14 May 2016 12:25:13 +0300
From: Eli Zaretskii <address@hidden>
Cc: address@hidden, Jim Meyering <address@hidden>
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
I don't remember much myself, but the issue is this (and it is documented):
It's commented rather documented:-)

Well, there is no technical documentation like for most other packages. The code is documented though (more or less :-)

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.

Right, it has to do its own marking.  When something gets viper-undone, the latest viper-buffer-undo-list-mark is deleted and is replaced with a nil, so that things can be further viper-undone.

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.

I am not sure what you are referring to here.

Sorry that I don't have much time these days to work on viper.  :-(
Too busy doing all logic and semantics?

Something like that.
Viper is not the only open-source thing out there :-)


       --- michael


reply via email to

[Prev in Thread] Current Thread [Next in Thread]