Luke Gorrie luke@bluetail.com writes:
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?
An 'eval-when-compile' would be 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.
I don't see this warnings in Emacs 21.3.50 a half year old CVS version. Perhaps we should wrap (require 'cl) inside a eval-and-compile?
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.
I think the policy is that packages that are dumped with Emacs should not load the cl package. Gnus is part Emacs and also depends on 'cl, but it is not the image. So, loading 'cl should not prevent SLIME from being becoming part of Emacs.
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!"
I'm in the "Use 'cl' to our heart's content." department. Not using 'cl means reinventing many wheels.
Helmut.