Date: Fri, 29 Jun 2007 09:22:26 +0200 From: "Tobias C. Rittweiler" tcr@freebits.de
The nice thing about the current behaviour is that it's (perhabs arguably) convenient if the host Lisp provides appropriate continuation restarts.
Restarts do make it possible to work around these situations, but I'd hardly call it `convenient'. The situations to which I refer are those in which there really is a uniquely best course of action -- for Emacs to present a message to the user, and for the user to behave better --, so entering a debugger at all is just an impediment to the user's flow. Using the condition system at all for such cases doesn't make much sense: the whole purpose of it is to allow programs to defer to other parts of the program the decision of what course of action to take, when there are multiple possibilities between which none is obviously best.
I have done some work to take these messages into account at the REPL (cf. entry 2007-05-14)
Oops! I was looking at CVS from 2007-05-13. I shall endeavour to remember to update CVS before making inquiries on the mailing list...
-- 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!)
[...]
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.)
It is true that I have an obvious interested in SLIME48, but I think that it is also worth considering in Common Lisp. My (possibly wrong) idea of the architecture of CL Swank is that there is the back end, which implements non-portable extensions to Common Lisp that are useful in IDEs, and the implementation of the RPCs. The back end is (theoretically) useful independent of the specific integration with Emacs, and the RPCs are for the most part just wrappers around the functionality of Common Lisp and the Swank back end necessary to present information palatably to Emacs. In my model, the RPC functions (i.e. everything defined with DEFSLIMEFUN) are the only places in the code that ABORT-REQUEST should ever be invoked in code, because they themselves are expected to be invoked only by remote call from Emacs; everything else should use the condition system to report problems.
Now, obviously, real errors in RPC implementations should trigger the debugger, and the debugger is always an acceptable substitute if an RPC implementation fails to properly check its arguments. But I think that it would be preferable for anything invoked by Emacs through the RPC server to call ABORT-REQUEST with a useful report, and for anything intended to be invoked by arbitrary Common Lisp clients to use the condition system.
Personally, in the case of DECODE-KEYWORD-ARG, I'd use the condition system to report errors: it looks to me like any error there is a bug worthy of debugging anyway, because it should only ever receive its arguments from within the Common Lisp system, which is presumably in an inconsistent state if it yields an invalid argument list.
I could also have a completely wrong idea about this, because I didn't design it, and never discussed its design at any great length with its designers; this is just what I have concluded from my understanding of the code.