diff lisp/emulation/viper-macs.el @ 93615:34417c118a39

2008-04-03 Michael Kifer <[e-mail]> * 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.

--- a/lisp/emulation/viper-macs.el	Thu Apr 03 20:06:46 2008 +0000
+++ b/lisp/emulation/viper-macs.el	Thu Apr 03 21:04:18 2008 +0000
@@ -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 @@
   (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))