I'm using a SLIME snapshot from October 13th.
When I use slime-who-calls to list the calls to a function (e.g. ql-http:fetch), the frame splits, and the window with the xref info shows something like this:
/Users/xach/src/quicklisp-client/dist.lisp (DEFMETHOD ENSURE-SYSTEM-INDEX-FILE (DIST)) (DEFMETHOD ENSURE-LOCAL-ARCHIVE-FILE (RELEASE)) (DEFMETHOD ENSURE-RELEASE-INDEX-FILE (DIST)) (DEFMETHOD AVAILABLE-VERSIONS (DIST)) /Users/xach/src/quicklisp-client/dist-update.lisp INSTALL-DIST (DEFMETHOD AVAILABLE-UPDATE (DIST)) ...
The cursor is placed at the beginning of the first line.
As I move my cursor down in the xref window, the other window jumps to each use of the function that corresponds to the line containing the cursor.
However, when the cursor reaches the second file pathname line, the xref buffer is replaced in the window with a buffer showing the file in question. I can no longer move up and down in the xref buffer to show calls to the function.
I expected to be able to continue to use the xref buffer until I hit SPACE for slime-goto-xref, or used some other window management option to close it.
Are my expectations reasonable? Have I possibly screwed up my local configuration? Is the behavior different in CVS slime? What would you recommend I do?
Thanks, Zach
On Sun, Nov 25 2012, Zach Beane wrote:
I'm using a SLIME snapshot from October 13th.
When I use slime-who-calls to list the calls to a function (e.g. ql-http:fetch), the frame splits, and the window with the xref info shows something like this:
/Users/xach/src/quicklisp-client/dist.lisp (DEFMETHOD ENSURE-SYSTEM-INDEX-FILE (DIST)) (DEFMETHOD ENSURE-LOCAL-ARCHIVE-FILE (RELEASE)) (DEFMETHOD ENSURE-RELEASE-INDEX-FILE (DIST)) (DEFMETHOD AVAILABLE-VERSIONS (DIST)) /Users/xach/src/quicklisp-client/dist-update.lisp INSTALL-DIST (DEFMETHOD AVAILABLE-UPDATE (DIST)) ...
The cursor is placed at the beginning of the first line.
As I move my cursor down in the xref window, the other window jumps to each use of the function that corresponds to the line containing the cursor.
However, when the cursor reaches the second file pathname line, the xref buffer is replaced in the window with a buffer showing the file in question. I can no longer move up and down in the xref buffer to show calls to the function.
Usually the cursor skips over the pathname line, e.g. when you are at (DEFMETHOD AVAILABLE-VERSIONS (DIST)) and press the cursor down key then the cursor moves ahead to INSTALL-DIST.
I expected to be able to continue to use the xref buffer until I hit SPACE for slime-goto-xref, or used some other window management option to close it.
That what is supposed to happen and works like this for me.
Are my expectations reasonable? Have I possibly screwed up my local configuration? Is the behavior different in CVS slime? What would you recommend I do?
Moving around in the xref buffer will eventually call slime-show-source-location. There we use save-selected-window that should prevent the kind of behavior that you describe. Maybe you have some Emacs version where save-selected-window is broken? You could insert some debug code like:
(defun slime-show-source-location (source-location &optional no-highlight-p) (message "before: %s %s" (current-buffer) (selected-window)) (save-selected-window ; show the location, but don't hijack focus. (slime-goto-source-location source-location) (unless no-highlight-p (slime-highlight-sexp)) (slime-show-buffer-position (point))) (message " after: %s %s" (current-buffer) (selected-window)))
and then look in the *Messages* buffer to verify that the buffer was actually changed.
Helmut
Helmut Eller heller@common-lisp.net writes:
Are my expectations reasonable? Have I possibly screwed up my local configuration? Is the behavior different in CVS slime? What would you recommend I do?
Moving around in the xref buffer will eventually call slime-show-source-location. There we use save-selected-window that should prevent the kind of behavior that you describe. Maybe you have some Emacs version where save-selected-window is broken?
Thanks. I upgraded from a snapshot of Emacs 24.0 to the release of 24.2 and now the problem is gone.
Zach