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

[phillip.lord@russet.org.uk (Phillip Lord)]

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

>> 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.
>
> In VI, an undo is supposed to undo the effect of the previous VI
> command. In Emacs terms, each such command usually means several
> inserts and deletes, which in Emacs would be undone via a series of
> undos. Such behavior is a non-no to a vi user.


Actually, by default inserts and (simple) deletes are amalgamated by
Emacs and undone in chunks of 20 rather than one at a time.


> I was referring to the insertion of a special marker into the undo
> list. Obviously, the usual Vi conventions are not documented because
> this would require to duplicate the Vi manual.

Actually, that would be a useful statement to have. Viper may replicate
"vi" behaviour, although I don't have a copy of vi to test it on. It
doesn't replicate vim's undo.


>> 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.
>
> This would be a non-starter and would cause a mass migration to vim.
> The undo would also then be implementation dependent. If, say, "delete
> 2 words" is implemented differently from how it is now then it would
> be undone via a different sequence of commands.

People will get a different sequence of commands if they migrate to vim
also!

Anyway, I have sent more code upstream. It changes the implementation,
but (hopefully) will preserve the currrent behaviour.

Phil