[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: |
Sat, 14 May 2016 21:39:34 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux) |
Michael Kifer <kifer@cs.stonybrook.edu> writes:
> On 05/14/2016 09:57 AM, Phillip Lord wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Date: Sat, 14 May 2016 12:25:13 +0300
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>> Cc: 22295@debbugs.gnu.org, Jim Meyering <jim@meyering.net>
>>
>> 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
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Eli Zaretskii, 2016/05/14
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Eli Zaretskii, 2016/05/14
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Phillip Lord, 2016/05/14
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Michael Kifer, 2016/05/14
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14,
Phillip Lord <=
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Michael Kifer, 2016/05/14
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Phillip Lord, 2016/05/16
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Michael Kifer, 2016/05/16
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Phillip Lord, 2016/05/17
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Michael Kifer, 2016/05/17
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Michael Albinus, 2016/05/16
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Phillip Lord, 2016/05/16
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Michael Kifer, 2016/05/16
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Jim Meyering, 2016/05/15
- bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14, Phillip Lord, 2016/05/16