|Subject:||bug#22295: viper-mode undo bug introduced between Nov 10 and Nov 14|
|Date:||Mon, 16 May 2016 23:38:56 -0400|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2|
On 05/16/2016 05:50 AM, Phillip Lord wrote:
Michael Kifer <address@hidden> writes:Right, it has to do its own marking. When something gets viper-undone, the latest viper-buffer-undo-list-mark is deleted and is replaced with a nil, so that things can be further viper-undone. Hope this helps.It does yes. I am working on a solution; I think that the undo changes mean that this should be easier to implement.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. I am not sure what you are referring to here.Consider this: (defcustom viper-mode (cond (noninteractive nil) (t 'ask)) ..... And the viper-mode function... (defun viper-mode () "Turn on Viper emulation of Vi in Emacs. See Info node `(viper)Top'." (interactive) (if (not noninteractive) (progn 'actually-turn-viper-mode-on.....) (if (eq major-mode 'viper-mode) (setq major-mode 'fundamental-mode)) ) I normally run tests in batch, but viper automatically switches itself off. It's going to make testing viper essentially impossible without working around it (easy to do, but it would be good to understand why it's like this).
OK. I don't remember this very clearly but there are cases (which I don't remember) where viper-mode gets kicked in implicitly for buffers where
the user didn't ask it to and where it is not wanted. Maybe when one runs emacs in batch mode as a scripting tool. One can defeat viper-mode in that case using emacs -q, but maybe there are other cases.
Since I don't remember and since it is not good to have kludges around, one way to figure it out is to comment out the (not interactive) part and then see what happens.
If and when you see undesired behavior, then uncomment and document :-)
|[Prev in Thread]||Current Thread||[Next in Thread]|