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

[Michael Kifer]

On 05/17/2016 04:46 AM, Phillip Lord wrote:

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.

Yes, but this is semantically meaningless for vi.

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.

I used to have (may still have) access to Solaris where the One True Vi could still be found :-)
True, vim undo is slightly different. But I am not sure there was a vim back when viper started.
Besides, the '.' came from a precursor of viper, introduced by someone else, so I am not responsible :-)
After all these years using it I prefer the viper behavior.

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.

Cool, thanks!

--

       --- michael