Hi,
I would like to report a small problem in Slime. Here is the scenario:
1. On a lisp file, change one definition and slime-compile-defun it (C-c C-c).
2. Save the changed buffer.
3. Kill the saved buffer.
4. slime-edit-definition for the changed definition.
5. Emacs complains that it is trying to set-buffer on a non-existent buffer.
This occurs with, at least, SBCL, CMUCL, and Allegro.
As far as I can see, the problem is that the implementation of swank-compile-string (which is used by slime-compile-defun) ignores the buffer's filename-directory and this makes it impossible for emacs to recover the correct file. I agree that when we are using a buffer that is not connected to a file, that's the proper behavior. However, IMHO, that's not a frequent situation.
To solve this problem for Allegro, I made the following quick (and ugly) hack in swank-allegro.lisp:
(defimplementation swank-compile-string (string &key buffer position directory) ;; We store the source buffer in excl::*source-pathname* as a string ;; of the form <buffername>;<start-offset>. Quite ugly encoding, but ;; the fasl file is corrupted if we use some other datatype. (with-compilation-hooks () (let ((*buffer-name* buffer) (*buffer-start-position* position) (*buffer-string* string) (*default-pathname-defaults* (if directory (merge-pathnames (pathname directory)) *default-pathname-defaults*))) (compile-from-temp-file (format nil "~S ~S~%~A" `(in-package ,(package-name *package*)) `(eval-when (:compile-toplevel :load-toplevel) (setq excl::*source-pathname* ,(format nil "~A~A;~D" (or directory "") buffer position))) string)))))
Then, to recover the source pathname, I changed the following function:
(defun find-definition-in-buffer (filename) (let ((directory-p (find #/ filename :from-end t))) (let ((pos (position #; filename :from-end t))) (multiple-value-bind (name position) (values (subseq filename 0 pos) (parse-integer (subseq filename (1+ pos)))) (make-location (if directory-p (list :file name) (list :buffer name)) (list :position position))))))
As I said before, it's not a pretty solution :-)
Best regards,
António Leitão.