I have more information on this bug, although I still don’t have a reproducible case. The problem happens when the *global* value of viper-current-state is changed from emacs-state to vi-state. Once this happens we are in trouble, because new buffers will not be assigned the vi key-bindings so anything other than cursor movement keys and a few others will do nothing. I made the following changes to viper-cmd.el in the function viper-change-state:
;; Always turn off quail mode in vi state
(cond ((eq new-state 'vi-state) (viper-set-input-method nil)) ;intl input off
(viper-special-input-method (viper-set-input-method t)) ;intl input on
(t (viper-set-input-method nil)))
(message (concat "Setting viper-current-state from " (prin1-to-string viper-current-state) " to " (prin1-to-string new-state) " via setq"))
(global-viper-current-state)
(setq viper-current-state new-state)
(global-viper-current-state)
Global-viper-current-state is defined as follows:
(defun global-viper-current-state ()
(message (concat "The global value of viper-current-state is " (prin1-to-string (default-value 'viper-current-state)))))
Most of the time I see the following:
Setting viper-current-state from emacs-state to insert-state via setq
The global value of viper-current-state is emacs-state [2 times]
But then, for no reason that I could see, I saw this:
Setting viper-current-state from emacs-state to vi-state via setq
The global value of viper-current-state is emacs-state
The global value of viper-current-state is vi-state
How on Earth? Perhaps setq is broken. Perhaps we aren’t actually *in* a buffer when setq is called (is that possible?) and thus the global value is being set. I don’t understand how this is possible and, now that I’ve uncovered this, I’m not sure what I can do to fix it.
Alan