[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: Phillip Lord
Subject: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14
Date: Sat, 14 May 2016 21:39:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux)

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
>> '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?


reply via email to

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