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

From: [email-masked] (Phillip Lord)
Date: Sat, 14 May 2016 21:39:34 +0100

Michael Kifer <[email-masked]> writes:

> On 05/14/2016 09:57 AM, Phillip Lord wrote:
>> Eli Zaretskii <[email-masked]> writes:
>>
>>>> Date: Sat, 14 May 2016 12:25:13 +0300
>>>> From: Eli Zaretskii <[email-masked]>
>>>> Cc: [email-masked], Jim Meyering <[email-masked]>
>>
>> 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