Using M-. with a generic function presents a buffer selection thingy. Selecting the desired method or defclass opens the desired buffer but then using q to exit the xrefs buffer restores de window configuration so I have to select the buffer manually. Using C-x o to exit the xref buffer leaves it visible but this is something I want to avoid. So I have installed locally the following patch:
Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.477 diff -u -r1.477 slime.el --- slime.el 1 Apr 2005 19:58:20 -0000 1.477 +++ slime.el 1 Apr 2005 21:07:24 -0000 @@ -6065,12 +6066,14 @@ (error "No context for finding locations.")) (funcall slime-next-location-function))
-(defun slime-xref-quit () - "Kill the current xref buffer and restore the window configuration." - (interactive) +(defun slime-xref-quit (arg) + "Kill the current xref buffer and restore the window configuration. +If arg is supplied do not restore configuration." + (interactive "P") (let ((config slime-xref-saved-window-configuration)) (slime-xref-cleanup) - (set-window-configuration config))) + (unless arg + (set-window-configuration config))))
(defun slime-xref-cleanup () "Delete overlays created by xref mode and kill the xref buffer."
----------------------------
The feature request is to send more arguments to slime-translate-to-lisp-filename-function and her sister slime-translate-from-lisp-filename-function, say (lisp-implementation-version) and (machine-instance). I am no elisp expert and failed to work out something like this. The idea is to be able to know if the translation is really needed (emacs on windows, lisp on linux) or not (everything on linux). The easy part is to know where emacs is running and the hard one (that I leave to fine slime hackers :) is to know the lisp host environment.
Greetings,
Eduardo Muñoz emufer@terra.es writes:
Using M-. with a generic function presents a buffer selection thingy. Selecting the desired method or defclass opens the desired buffer but then using q to exit the xrefs buffer restores de window configuration so I have to select the buffer manually. Using C-x o to exit the xref buffer leaves it visible but this is something I want to avoid.
Try selecting the method you want with SPC instead of RET. That way you will be jumped to the definition and the xref buffer will be dismissed.
I updated the mode description to explain this for `C-h m'.
* Luke Gorrie luke@synap.se | Eduardo Muñoz emufer@terra.es writes: | | > Using M-. with a generic function presents a buffer | > selection thingy. Selecting the desired method or defclass | > opens the desired buffer but then using q to exit the xrefs | > buffer restores de window configuration so I have to select | > the buffer manually. Using C-x o to exit the xref buffer | > leaves it visible but this is something I want to avoid. | | Try selecting the method you want with SPC instead of RET. That way | you will be jumped to the definition and the xref buffer will be | dismissed.
Sweet, thanks :)
Eduardo Muñoz emufer@terra.es writes:
The feature request is to send more arguments to slime-translate-to-lisp-filename-function and her sister slime-translate-from-lisp-filename-function, say (lisp-implementation-version) and (machine-instance). I am no elisp expert and failed to work out something like this. The idea is to be able to know if the translation is really needed (emacs on windows, lisp on linux) or not (everything on linux). The easy part is to know where emacs is running and the hard one (that I leave to fine slime hackers :) is to know the lisp host environment.
I've added elisp functions slime-lisp-implementation-version and slime-machine-version. The values are initialized at startup.
Btw, you could have used something like
(slime-eval '(cl:lisp-implementation-version))
to access the value and slime-connected-hook is probably a good place to setup the filename translation.
Helmut.
* Helmut Eller heller@common-lisp.net | Eduardo Muñoz emufer@terra.es writes: | | > The feature request is to send more arguments to | > slime-translate-to-lisp-filename-function and her sister | > slime-translate-from-lisp-filename-function, say | > (lisp-implementation-version) and (machine-instance). I am | > no elisp expert and failed to work out something like | > this. The idea is to be able to know if the translation is | > really needed (emacs on windows, lisp on linux) or not | > (everything on linux). The easy part is to know where emacs | > is running and the hard one (that I leave to fine slime | > hackers :) is to know the lisp host environment. | | I've added elisp functions slime-lisp-implementation-version and | slime-machine-version. The values are initialized at startup.
Thank for the change.
| Btw, you could have used something like | | (slime-eval '(cl:lisp-implementation-version)) | ...
I could had I know that it existed. I was not evident how to implement this functionality with my knowledge of slime protocols (almost zilch) and elisp. So thanks again for implementing this feature. :)
For the curious here are the functions that I use in its final state:
(defun emacs-running-on-windows () (string-match "\(somehost\|otherhost\)" (system-name)))
(defun lisp-running-on-linux () (string-match "\(|lispserver\foobar\)" (slime-machine-instance)))
(defun my-translate-to-lisp (here) ;; from e:/ to /home/emf/ (if (and (emacs-running-on-windows) (lisp-running-on-linux)) ;; subseq strips drive letter & colon (concat "/home/emf/" (subseq here 3)) here))
(defun my-translate-from-lisp (there) ;; viceversa (if (and (emacs-running-on-windows) (lisp-running-on-linux)) (concat "e:/" (subseq there (length "/home/emf/"))) there))
(setq slime-translate-to-lisp-filename-function 'my-translate-to-lisp slime-translate-from-lisp-filename-function 'my-translate-from-lisp)
-
Eduardo Muñoz -
Helmut Eller -
Luke Gorrie