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

From: [email-masked] (Phillip Lord)
Date: Tue, 17 May 2016 09:25:36 +0100

Eli Zaretskii <[email-masked]> writes:

>> One more, then. Starting with this input:
>> 
>>   1 2 3 4 5 6
>> 
>> advance to the '2' with 'w', 'dw' to delete the 2, then three '.'s to
>> delete the 3, then 4 and 5.
>> Then begin to undo with 'u', then '.' to repeat it. Those first two
>> work, restoring the 5 and 4.
>> However, one more '.' restores both the 3 and the 2.
>
> Thanks.  It now looks like your expectations are close to what Emacs
> does by default, whereas Michael said the VI undo is more coarse (and
> in the original recipe, it indeed seemed to be that).
>
> Is it possible to have a more general/formal description of what
> 'undo' in VI is supposed to do?  E.g., it looks like it has different
> granularities wrt insertions and deletions, is that correct?
>
> You see, when I said this is undocumented, I meant precisely that: the
> expected effect of 'undo' in VI is not described, so someone who is
> not a VI user doesn't know what to test and how to program that.

AFAICT, once you enter insert mode, it squashes all undo boundaries,
until you leave again. Unfortunately, outside of insert mode (i.e. in
"vi" mode), it uses the default "one per command" emacs undo.

> Michael said that this _is_ documented, but the only documentation I
> see is comments that describe _what_ they do in terms of Emacs undo
> structures, and are full of "rationale" such as "so that things will
> be undone properly".  I don't see any description of the expected
> effect of undoing in different situations, let alone some formal
> specification of undo-related requirements.  If I missed some
> description of how undo is supposed to work in viper, please just
> point me there.

I guess it's "the same as vi". Although, the undo behaves differently
from vim at least: viper has "u" == "undo" and "." == "undo more". VIM
just uses repeated "u"'s to achieve the same thing.

> Another alternative is to make viper use the default Emacs undo, and
> then ask you and other users of viper to tell where the results don't
> match your expectations.  It could well be that starting with a clean
> slate will get us to the goal faster and with less complex code.
>
> TIA

It mostly does use the default Emacs undo, with a bit of weirdness in
one mode.

Phil