Well, I don't know if you consider it a but, but it sure seems like it. If you have a Tramp translations set up via Slime, it matches the translation off of the value given by (machine-instance). All is fine and good except that if you try to start a new local connection with `M-x slime' and your computer doesn't have the same (machine-instance) as the remote Lisp, Tramp gets confused as it uses the current connection to evaluate (machine-instance), then uses that to calculate the translation and it uses that translation to change the value used in the Swank load form for the new local Lisp image:
(progn (load <<some-tramp-mangled-path>> :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") <<some-other-mangled-path>> :coding-system "utf-8-unix"))
This makes the slime startup die at:
debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD "initial thread" RUNNING {1002941271}>: Couldn't load <<mangled>>: file does not exist.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level.
(LOAD <<mangled>> :VERBOSE T :PRINT NIL :IF-DOES-NOT-EXIST T :EXTERNAL-FORMAT :DEFAULT) 0]
It would be nice if Slime by-passed Tramp completely on startup when invoked via `M-x Slime' (and perhaps always?). I did this by wrapping the SLIME body with a binding setting SLIME-FILENAME-TRANSLATIONS to nil, and I think it works. Here is a patch (this is my first time doing this, but I generated with M-x diff-buffer-with-file from Emacs; It is diffed against the probably pretty dated Slime, sorry):
diff -c /home/smithzv/quicklisp/dists/quicklisp/software/slime-20110829-cvs/slime.el /tmp/buffer-content-14752oJk *** /home/smithzv/quicklisp/dists/quicklisp/software/slime-20110829-cvs/slime.el 2011-09-02 13:42:13.982182004 -0600 --- /tmp/buffer-content-14752oJk 2011-10-06 18:21:02.031020994 -0600 *************** *** 1076,1082 **** (defun slime (&optional command coding-system) "Start an inferior^_superior Lisp and connect to its Swank server." (interactive) ! (let ((inferior-lisp-program (or command inferior-lisp-program)) (slime-net-coding-system (or coding-system slime-net-coding-system))) (slime-start* (cond ((and command (symbolp command)) (slime-lisp-options command)) --- 1076,1083 ---- (defun slime (&optional command coding-system) "Start an inferior^_superior Lisp and connect to its Swank server." (interactive) ! (let ((slime-filename-translations nil) ! (inferior-lisp-program (or command inferior-lisp-program)) (slime-net-coding-system (or coding-system slime-net-coding-system))) (slime-start* (cond ((and command (symbolp command)) (slime-lisp-options command))
Diff finished. Thu Oct 6 18:21:02 2011
Zach Kost-Smith zachkostsmith@gmail.com writes:
Well, I don't know if you consider it a but, but it sure seems like it. If you have a Tramp translations set up via Slime, it matches the translation off of the value given by (machine-instance). All is fine and good except that if you try to start a new local connection with `M-x slime' and your computer doesn't have the same (machine-instance) as the remote Lisp, Tramp gets confused as it uses the current connection to evaluate (machine-instance), then uses that to calculate the translation and it uses that translation to change the value used in the Swank load form for the new local Lisp image:
For anyone who decides the fate of this bug report:
I've filed a bug report on this issue 6 months ago https://bugs.launchpad.net/slime/+bug/756691. Please adjust its status to reflect your decision also.