My Emacs (GNU Emacs 21.3.50.1 / MacOSX) had a little trouble compiling 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?
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
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 think this is a political issue more than anything else... the GNU Emacs maintainers don't like cl to the extent that they create warnings for it; the XEmacs folks don't.
I'm not sure to what extent cl.el modifies emacs-lisp behaviour; in Common Lisp you would have to use a macro, or wrap the defun in an eval-when clause :-)
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.
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?
Oops, now I see the problem. The macro was calling a function that wasn't defined at compile time. I didn't catch that at first, since I had already loaded slime and thus defined it.
I checked in a fix.
-
Helmut Eller -
Luke Gorrie -
Raymond Wiker