Taylor R Campbell campbell@mumble.net writes:
(I asked about this a year ago, but must have forgotten about it.)
There are many cases where a user invoked a command that doesn't make any sense, so the RPC can't complete with a meaningful answer, but it would also be overkill to throw the user into a debugger. It would be nice to abort the RPC with a message to the user, such as `Package does not exist' for `slime-repl-set-package' or `Undefined function' for `slime-disassemble-symbol'.
The nice thing about the current behaviour is that it's (perhabs arguably) convenient if the host Lisp provides appropriate continuation restarts.
It looks like there was once a time when a message could be supplied with a :ABORT result from an RPC, and there are some vestigial remnants of support for it -- `slime-rex' forms with (:ABORT &OPTIONAL REASON), and indeed the documentation of `slime-rex' says that the reason is not optinoal --, but there are many other uses that prohibit a reason from being supplied.
Is there a good reason for :ABORT responses not to have an optional message associated with them, or would a patch be welcomed for all of the uses of `slime-rex' to consistently accept an optional message?
I have done some work to take these messages into account at the REPL (cf. entry 2007-05-14) -- however, the problem is not so much with "accepting messages from Slime", but that not much code in SWANK appropriately calls SWANK:ABORT-REQUEST (and maybe rightly so!)
For instance, take the following into consideration:
CL-USER> (swank::decode-keyword-arg '#(1 2 3)) ; Evaluation aborted: Bad keyword item of formal argument list
CL-USER> (swank::decode-keyword-arg '(#(1 2 3))) ; ==> thrown into debugger with ; ; The value #(1 2 3) is not of type SYMBOL. ; [Condition of type TYPE-ERROR]
The difference is that the first case is explicitly handled with an invokation of ABORT-REQUEST. Similiarly to make the cases you mentioned above actually return a message, the respective functions of SWANK would have to be modified to test for bad data, and invoke ABORT-REQUEST accordingly.
That is not to say that I'm against your proposed changes to slime.el. (And of course, I can figure that you probably want that for SLIME48, so the SWANK side is not as much of a matter for you.)
-T.