Edi Weitz edi@agharta.de writes:
- The function slime-remove-notes is bound to C-c M-c while the manual says M-c.
Should be fixed now.
- The shortcut ,change-directory uses a function read-directory-name which I don't seem to have. I'm using GNU Emacs 21.3.
I included definition from CVS Emacs.
- Is there a specific reason that RET isn't bound to newline-and-indent (or something similar) as in ILISP but only to C-j?
This is a somewhat theological question. I think the primary reason is that RMS likes to use C-j, but I assume other people like C-j too. I think it is the official convention for all programming modes. Perhaps there is already some way to customize it.
Anyway, newline-and-indent does not quite belong to SLIME, it belongs to lisp-mode. All we can do is to override the binding in the lisp-mode-map. I think a discussion about C-j vs. RET would be more productive on emacs.devel or comp.emacs than here.
Load CL-PPCRE, than invoke slime-apropos-package (a cool function by the way). Now position the cursor above PPCRE-SYNTAX-ERROR and invoke slime-edit-definition. I get:
No matching method for the generic-function #<Standard-Generic-Function PCL:COMPUTE-APPLICABLE-METHODS-USING-CLASSES (1) {281DF8F1}>, when called with arguments (#<Closure Over Function "DEFUN %DEFINE-CONDITION" {4879E009}> (#<CONDITIONS::CONDITION-CLASS PPCRE-SYNTAX-ERROR {486B867D}>)). [Condition of type NO-APPLICABLE-METHOD]
In the same *SLIME Apropos* buffer position the cursor above CREATE-SCANNER and invoke slime-edit-definition. Now I get:
Error in function COMMON-LISP::%%TYPEP: Unknown type specifier: C::FILE-SOURCE-LOCATION [Condition of type SIMPLE-ERROR]
This is due to differences in CMUCL 18e and the current snapshots. I added some workarounds and CVS SLIME shouldn't break, but cannot cannot find the location in 18e. I guess we need better tests to avoid regressions like this.
- I think that slime-interactive-eval is a very useful function and IMHO the C-c : keybinding should also be available in the Slime REPL. Yeah, I know that you actually don't need to use the minibuffer while you're in the REPL but in the long run it'd be easier for my muscle memory to always be sure that C-c : is there without thinking... :)
That's true. Fixed in CVS.
Thanks to all for this great package!
And thank you for the feedback.
Helmut.
On 21 Apr 2004 00:59:25 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
This is a somewhat theological question. I think the primary reason is that RMS likes to use C-j, but I assume other people like C-j too. I think it is the official convention for all programming modes. Perhaps there is already some way to customize it.
Anyway, newline-and-indent does not quite belong to SLIME, it belongs to lisp-mode. All we can do is to override the binding in the lisp-mode-map. I think a discussion about C-j vs. RET would be more productive on emacs.devel or comp.emacs than here.
More appropriate - maybe. More productive - I don't think so... :)
I'll stick to my own keybindings, I don't like theological discussions... :)
This is due to differences in CMUCL 18e and the current snapshots.
OK. I wanted to try a pre-19 snapshot anyway.
Thanks for the quick fixes, Edi.
PS: BTW, I've just built GNU Emacs 21.3.50 from CVS and when I started slime I got a message about a mismatch between the Elisp and swank dates or somesuch (sorry, I forgot to keep it). The slime REPL didn't start and I was in the normal inferior-lisp buffer instead. I removed the FASL files and restarted slime and everything was fine again (swank was recompiled). However, I thought I had read somewhere that swank would be automatically recompiled if needed. Am I wrong?
Edi Weitz edi@agharta.de writes:
PS: BTW, I've just built GNU Emacs 21.3.50 from CVS and when I started slime I got a message about a mismatch between the Elisp and swank dates or somesuch (sorry, I forgot to keep it). The slime REPL didn't start and I was in the normal inferior-lisp buffer instead. I removed the FASL files and restarted slime and everything was fine again (swank was recompiled). However, I thought I had read somewhere that swank would be automatically recompiled if needed. Am I wrong?
The swank code is recompiled if the one of the .lisp source files is newer than the corresponding fasl file and Emacs asks if he should recompile slime.el if an old slime.elc lies around. But we just abort when the Lisp and ELisp versions are out sync. Not sure if a more automatic mechanism is worth the trouble.
Helmut.
On Wed, 21 Apr 2004 01:37:49 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
The swank code is recompiled if the one of the .lisp source files is newer than the corresponding fasl file and Emacs asks if he should recompile slime.el if an old slime.elc lies around. But we just abort when the Lisp and ELisp versions are out sync.
OK, I see.
Not sure if a more automatic mechanism is worth the trouble.
I don't think so.
Helmut Eller wrote:
[...]
The swank code is recompiled if the one of the .lisp source files is newer than the corresponding fasl file and Emacs asks if he should recompile slime.el if an old slime.elc lies around. But we just abort when the Lisp and ELisp versions are out sync. Not sure if a more automatic mechanism is worth the trouble.
On the swank side, I suppose you could signal a swank-files-too-old condition, or something, which the user could then handle appropriately, rather than just dying completely, since the current method requires that one touch one of the lisp files and restart the server, etc... On the emacs side, one could do clever things by reloading slime.el if there is a protocol mismatch.
e.g. (lexical-let ((tries 0)) (defun slime-check-for-protocol-mismatch (lisp-version) (while (and (< (incf tries 2)) (version-mismatch)) (load-file "slime.el"))))
or something.
Lawrence Mitchell wence@gmx.li writes:
Helmut Eller wrote:
But we just abort when the Lisp and ELisp versions are out sync. Not sure if a more automatic mechanism is worth the trouble.
I think both should just generate warnings rather than erroring out -- it makes much more sense to warn the user and give him/her a chance to continue:
(unless (y-or-n-p "Version mismatch with $FILE. Proceed anyways?") (error ...))
than to simply refuse to start.
/s
"Sean O'Rourke" seano@cs.ucsd.edu writes:
I think both should just generate warnings rather than erroring out -- it makes much more sense to warn the user and give him/her a chance to continue:
(unless (y-or-n-p "Version mismatch with $FILE. Proceed anyways?") (error ...))
than to simply refuse to start.
I decided not to bother and stay with current simple and predictable strategy.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
The swank code is recompiled if the one of the .lisp source files is newer than the corresponding fasl file and Emacs asks if he should recompile slime.el if an old slime.elc lies around. But we just abort when the Lisp and ELisp versions are out sync. Not sure if a more automatic mechanism is worth the trouble.
I have added some code to auto-detect if slime.elc is older than slime.el -- I wonder if that would be sufficient now?
With stale bytecode out of the way AFAICS the ChangeLog test just catches people doing "cvs update" but then only restarting one of Emacs and Lisp. If word gets around that you should restart both Emacs and Lisp after a cvs update (unless you know what you're doing) then maybe that won't be such a big problem, and we can remove the test?
-Luke
Luke Gorrie luke@bluetail.com writes:
With stale bytecode out of the way AFAICS the ChangeLog test just catches people doing "cvs update" but then only restarting one of Emacs and Lisp.
The ChangeLog test is a bit to eager: it enforces a recompile of the Lisp code even if only slime.el changed.
If word gets around that you should restart both Emacs and Lisp after a cvs update (unless you know what you're doing) then maybe that won't be such a big problem, and we can remove the test?
Yes, removing the test is probably more convenient.
Helmut.
-
Edi Weitz -
Helmut Eller -
Lawrence Mitchell -
Luke Gorrie -
Sean O'Rourke