GNU bug report logs - #22295
viper-mode undo bug introduced between Nov 10 and Nov 14

Previous Next

Full log

Message #31 received at 22295 <at> debbugs.gnu.org (full text, mbox):

From: phillip.lord <at> russet.org.uk (Phillip Lord)
To: Michael Kifer <kifer <at> cs.stonybrook.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22295 <at> debbugs.gnu.org, jim <at> meyering.net
Subject: Re: bug#22295: viper-mode undo bug introduced between Nov 10 and Nov
 14
Date: Mon, 16 May 2016 10:50:31 +0100

Michael Kifer <kifer <at> cs.stonybrook.edu> 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).

Phil

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.