This is CVS HEAD from 5mins ago:
To reproduce:
M-x slime ; start SLIME C-x C-f foo.lisp ; get a buffer in lisp-mode C-c : ; Slime Eval: <Tab> ; slime-completie-symbol
The value NIL is not of type PACKAGE. [Condition of type TYPE-ERROR]
Restarts: 0: [ABORT] Return to SLIME toplevel. 1: [ABORT] Reduce debugger level (leaving debugger, returning to toplevel). 2: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
Backtrace: 0: (SWANK:COMPLETIONS "Eval: " NIL) 1: (SB-INT:EVAL-IN-LEXENV 2 (SWANK:COMPLETIONS "Eval: " NIL) #S(SB-KERNEL:LEXENV :FUNS NIL :VARS NIL :BLOCKS NIL :TAGS NIL :TYPE-RESTRICTIONS NIL :LAMBDA NIL :CLEANUP NIL :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (INHIBIT-WARNINGS . 1) (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL] 2: (SWANK:EVAL-STRING "(swank:completions "Eval: " nil)" NIL 19) 3: ("hairy arg processor for SWANK::READ-FROM-EMACS" #<FILE-STREAM for "a constant string" {9915711}>)
Michael Weber michaelw+slime@foldr.org writes:
This is CVS HEAD from 5mins ago:
To reproduce:
M-x slime ; start SLIME C-x C-f foo.lisp ; get a buffer in lisp-mode C-c : ; Slime Eval: <Tab> ; slime-completie-symbol
Should be fixed in the CVS version. Thanks for the report.
Helmut.
* Helmut Eller e9626484@stud3.tuwien.ac.at [2004-01-21T01:04+0100]:
Michael Weber michaelw+slime@foldr.org writes:
M-x slime ; start SLIME C-x C-f foo.lisp ; get a buffer in lisp-mode C-c : ; Slime Eval: <Tab> ; slime-completie-symbol
Should be fixed in the CVS version. Thanks for the report.
Well, not really. The bug moved, though.
C-c : <left> ; move cursor somewhere over "Eval:" (of the "Slime Eval:" prompt) ; one char to the left is enough here. <tab> ; *bang*
The reason is two-fold: 1. My emacs allows me to move point over the prompt (GNU/Emacs 21.3.50.1), and access it as regular input.
2. SWANK:COMPLETIONS gets all upset about a package ("Eval") it cannot find.
re 1: Attached is a patch (slime-minibuffer.patch), which narrows the minibuffer, so that the prompt is not accessible. The macro WITHOUT-MINIBUFFER-PROMPT should probably be called whenever something wants to read from the minibuffer (at least if tab completion is enabled).
BTW: XEmacs seems to do the Right Thing by default and does not allow the cursor to be moved over the prompt, and it does not have MINIBUFFER-PROMPT-END, so I conditionalized on it.
re 2: Attached is another patch (swank-completions.patch), making SWANK:COMPLETIONS handle non-existent packages without bombing. While I was there I removed the unneeded LET*.
I also tried to run SLIME-RUN-TESTS. Why it said "FAILED: Completion set is as expected.", I don't know. Works for me(tm).
Here is the relevant output:
* complete-symbol ** input: (cl:compile ((cl:compile cl:compile-file cl:compile-file-pathname cl:compiled-function cl:compiled-function-p cl:compiler-macro cl:compiler-macro-function) cl:compile)) FAILED: Completion set is as expected. ** input: (cl:foobar (nil )) Completion set is as expected. ** input: (cl::compile-file ((cl::compile-file cl::compile-file-pathname) cl::compile-file)) FAILED: Completion set is as expected. ** input: (cl:m-v-l ((cl:multiple-value-list cl:multiple-values-limit) cl:multiple-value-li)) FAILED: Completion set is as expected.
Cheers, Michael
Michael Weber michaelw+slime@foldr.org writes:
re 1: Attached is a patch (slime-minibuffer.patch), which narrows the minibuffer, so that the prompt is not accessible. The macro WITHOUT-MINIBUFFER-PROMPT should probably be called whenever something wants to read from the minibuffer (at least if tab completion is enabled).
BTW: XEmacs seems to do the Right Thing by default and does not allow the cursor to be moved over the prompt, and it does not have MINIBUFFER-PROMPT-END, so I conditionalized on it.
Emacs 20 behaves like XEmacs, so I think it was conscious change in Emacs 21. I haven't applied that patch.
re 2: Attached is another patch (swank-completions.patch), making SWANK:COMPLETIONS handle non-existent packages without bombing. While I was there I removed the unneeded LET*.
The problem occurred only in SBCL, because (let ((*package* nil))) is a type error in SBCL.
I also tried to run SLIME-RUN-TESTS. Why it said "FAILED: Completion set is as expected.", I don't know. Works for me(tm).
The LET is needed because we need proper a binding for *print-case*. That's the reason for the failed tests.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
re 2: Attached is another patch (swank-completions.patch), making SWANK:COMPLETIONS handle non-existent packages without bombing. While I was there I removed the unneeded LET*.
The problem occurred only in SBCL, because (let ((*package* nil))) is a type error in SBCL.
Heh. It's only a type error in sbcl, but it's undefined behaviour everywhere. The consequences are undefined if *package* is bound or set to anything that isn't a package object (see the Value Type section of the CLHS page for *PACKAGE*, and also section 1.4.4.22).
Cheers,
Christophe
-
Christophe Rhodes -
Helmut Eller -
Michael Weber