2008-04-03 Michael Kifer <kifer@cs.stonybrook.edu>

	* viper-macs.el (viper-read-fast-keysequence): use viper-read-event
	instead of viper-read-key.

	* viper.el (viper-mode): move the check for fundamental mode.

	* viper-utils.el (viper-get-saved-cursor-color-in-replace-mode)
	viper-get-saved-cursor-color-in-insert-mode): get rid of redundant
	let-statements.

	* viper*.el: replaced load with require in eval-when-compile.

1 files changed, 9 insertions, 7 deletions

diff --git a/lisp/emulation/viper-macs.el b/lisp/emulation/viper-macs.el
index a9e24f28e7b..448903da5c9 100644
--- a/lisp/emulation/viper-macs.el
+++ b/lisp/emulation/viper-macs.el
@@ -38,10 +38,8 @@
 ;; in order to spare non-viperized emacs from being viperized
 (if noninteractive
     (eval-when-compile
-      (let ((load-path (cons (expand-file-name ".") load-path)))
-	(or (featurep 'viper-cmd)
-	    (load "viper-cmd.el" nil t 'nosuffix))
-	)))
+      (require 'viper-cmd)
+      ))
 ;; end pacifier
 
 (require 'viper-util)
@@ -873,9 +871,13 @@ name from there."
   (let ((lis (vector event))
 	next-event)
     (while (and (viper-fast-keysequence-p)
-		(viper-keyseq-is-a-possible-macro lis macro-alist))
-      (setq next-event (viper-read-key))
-      ;;(setq next-event (viper-read-event))
+           (viper-keyseq-is-a-possible-macro lis macro-alist))
+      ;; Seems that viper-read-event is more robust here. We need to be able to
+      ;; place these events on unread-command-events list. If we use
+      ;; viper-read-key then events will be converted to keys, and sometimes
+      ;; (e.g., (control \[)) those keys differ from the corresponding events.
+      ;; So, do not use (setq next-event (viper-read-key))
+      (setq next-event (viper-read-event))
       (or (viper-mouse-event-p next-event)
 	  (setq lis (vconcat lis (vector next-event)))))
     lis))