Raymond Wiker Raymond.Wiker@fast.no writes:
My Emacs (GNU Emacs 21.3.50.1 / MacOSX) had a little troublecompiling the latest slime.el; it complained about the undefined function slime-inspector-expand-fontify. Examining this function, I thought it looked like it should be a macro instead of a function, so I changed "defun" to "defmacro". That seemed to work... is this the right fix?
Was it broken before that change? I don't think this is right -- the function is called from a macro to generate code.
It is really ugly to byte-compile slime.el because of all those "Warning: Function `foo' from cl package called at runtime" messages. I just read the cl-compat manual to see what the beef is, and the gist is that loading `cl' uses up a lot of the elisp namespace that may clash with other code.
Personally I like calling `cl' code at runtime because it is handy, and I think people should be expected to avoid naming clashes with the cl package in their own programs. If they don't, they'll get the clashes when cl is loaded to byte-compile some other library anyhow.
However, my opinion is obviously not shared by the Emacs developers, and they are wise people. Also, I hate the way inf-lisp and ILISP invade lisp-mode rather than creating separate minor-modes just for their own convenience, and don't want to commit similar sins. I also don't think we should do anything that would prevent SLIME from becoming a part of Emacs in the long run.
So, just curious, does anyone have strong feelings like
Use 'cl' to our heart's content. Try to minimize use of 'cl' at runtime, ultimately cut it out. "Stop using 'cl' right now, loading it is already breaking stuff!"
?
BTW, I've noticed that code generated by 'cl' macros is really horrible in the debugger. That is a separate reason to avoid the package when convenient.
-Luke