On Wed, 14 Jan 2004 09:36:08 +0900,
"Stephen J. Turnbull" <stephen(a)xemacs.org> said:
Nothing as far as I can see (but I'm not an expert on the
command
loop). It says it's a warning. The fact that there are internal
objects in the backtrace is a little bit worrying, but it does get
checked by `next-event-internal' so I guess it's expected, and OK.
I felt uneasy because the trace says
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0x28983b78> ...)
I don't really know the meaning, though.
Is XEmacs behavior otherwise different from what you expect?
When I used 21.5-b5, such warning never occured with icomplete and I
could exit from the minibuffer by hitting C-g only once. Also on
21.5-b16 without icomplete, I can exit from the minibuffer as the same
ordinary way.
I'm not sure if it is related, but sometimes I also experienced a
weird error saying "Symbol's function definition is void: nil" when I
hit a first key inside a minibuffer (any key in any command such as
find-file). Enabling debug-on-error produces the following backtrace:
Signaling: (void-function nil)
(dispatch-event "[internal]")
read-minibuffer-internal("M-x ")
byte-code("..." [standard-output standard-input prompt recursion-depth
minibuffer-depth t read-minibuffer-internal] 2)
read-from-minibuffer("M-x " nil #<keymap minibuffer-must-match-map size 9
0xf0f> nil read-command-history nil nil)
completing-read("M-x " [packages-split-package-path micro2 0 0 0 0 0
font-blink-interval 0 0 lisp-indent-function byte-nthcdr 0 0 0 0 0 prev-input-method
set-process-sentinel sort-lines w3m-cookie-set skk-file-exists-and-writable-p 0
pcomplete/chown 0 register-ccl-program oprocbuf 0 holiday-julian loop-steps
w3-next-document skk-cursor-set-color byte-compile-top-level ! get-translation-table
koi8-r product-set-family maybe-frame paren-match howm-congrats-format \( \) * thebuf
ccl-increment-ic - comint-previous-matching-input-string / jde-run \1 ...] commandp t nil
read-command-history nil)
read-command("M-x ")
execute-extended-command(nil)
call-interactively(execute-extended-command)
(dispatch-event "[internal]")
The error doesn't always happen. At least it happens just after I
enable skk-isearch, but not always after that (I haven't found the
trigger of the change yet). It is more annoyance because it
interrupts every command using a minibuffer.
How to reproduce in my environment:
1. start xemacs -vanilla
2. eval the following
(add-hook 'isearch-mode-hook 'skk-isearch-mode-setup)
(add-hook 'isearch-mode-end-hook 'skk-isearch-mode-cleanup)
3. hit C-s to enable skk-isearch and quit by C-g
4. do find-file or something using minibuffer, and hit any key
I'm using skk in mule-packages.
skk 1.23 1.23 MULE: Japanese Language Input Method.
Ah! If I finish skk-isearch normally (not using C-g), the error will
stop occuring. Probably skk-isearch-mode-cleanup does some tricks?
Everytime I wanted to switch to 21.5-beta newer than b5, these errors
interfered me and I reverted back to beta5....
Now I wonder if skk and icomplete are not well compatible with newer
21.5-beta. I'm not sure which (XEmacs or these packages) should be
fixed.
Regards,
--
Yoshiaki Kasahara
Computing and Communications Center, Kyushu University
kasahara(a)nc.kyushu-u.ac.jp