[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: Tue, 17 May 2016 09:46:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux)

Michael Kifer <address@hidden> 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

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


reply via email to

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