When I type program text with Slime, it tries to display function type. But when it such symbol is not created yet in lisp image, Slime displays error message in minibuffer:
Error in function SWANK::FIND-SYMBOL-OR-LOSE: Unknown symbol: "bla-bla-bla" [in #<The COMMON-LISP-USER package>])
If symbol exists, but is not function, error message is different:
(INTEGER -- Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.)
(This message was generated when I was editing ECASE construct).
Same error appears when I type in Slime REPL in fresh Lisp.
I use Emacs 21.3.1, CMU Common Lisp CVS snapshot 2003-12. I fetch Slime each night from CVS at 21:30 GMT (I know about special tag for stable versions, but I want to use unstable :).
The bug appeared two or three days ago. I expected such a bug to be noticed by developers soon, but it was not fixed in two or three days... :(
Ivan Boldyrev boldyrev+nospam@cgitftp.uiggm.nsc.ru writes:
[snip]
If symbol exists, but is not function, error message is different:
(INTEGER -- Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.)
What would you like to see instead? Nothing? "<not available>"?
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Ivan Boldyrev boldyrev+nospam@cgitftp.uiggm.nsc.ru writes:
[snip]
If symbol exists, but is not function, error message is different:
(INTEGER -- Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.)
What would you like to see instead? Nothing? "<not available>"?
Well, if we're wishing...
This commonly happens when we're inside some kind of macro, such as CASE in Ivan's particular case, or DEFUN (in the arglist). While it may not be possible to solve the problem in full generality, for common-lisp symbols naming macros it is possible to know whether the user is currently in a region which is directly program text, or whether he is typing a case matching clause, or an arglist, or a DEFCLASS slot description. So given that, in an ideal world, rather than looking at the nearest open parenthesis, one would look further back and figure out the semantics of the current form, not just assume that it's a macro or function call.
On the other hand, firstly I know nothing about emacs programming, so this may be neither practical nor possible; nor am I volunteering to learn enough to be able to evaluate this, so please feel free to tell me that this is way too hard wishlist pie-in-the-sky.
Christophe
On 8682 day of my life Helmut Eller wrote:
Ivan Boldyrev boldyrev+nospam@cgitftp.uiggm.nsc.ru writes:
[snip]
If symbol exists, but is not function, error message is different:
(INTEGER -- Error in KERNEL:%COERCE-TO-FUNCTION: the function INTEGER is undefined.)
What would you like to see instead? Nothing? "<not available>"?
Displaying nothing is OK for me. :)
But error messages during normal edit (especially long: two-line messages in minibuffer forces Emacs to resize one of other buffers and it is little pausing) are annoing.
Recognizing Common Lisp structures (as Christophe Rhodes suggest) would be fine, but there are probably least important things to do :)
Ivan Boldyrev boldyrev+nospam@cgitftp.uiggm.nsc.ru writes:
What would you like to see instead? Nothing? "<not available>"?
Displaying nothing is OK for me. :)
But error messages during normal edit (especially long: two-line messages in minibuffer forces Emacs to resize one of other buffers and it is little pausing) are annoing.
Recognizing Common Lisp structures (as Christophe Rhodes suggest) would be fine, but there are probably least important things to do :)
I implemented Christophe's suggestion. Emacs sends the operator names of the forms around point to Lisp and gets the arglist of the nearest function/macro back. So for "(etypecase foo (integer " you see "(etypecase keyform &body cases)" in the echo area, but for "(etypecase foo (string " you still get "(string a)". If no symbol in the list is fbound nothing is displayed. I hope the new behavior is more to your liking.
Thank you both for the suggestions.
Helmut.