I've asked the question to the slime mailing list but still didn't get
an answer so I hope that many folks here solved the problem and could
give me an advice.
I wonder how you guys navigate through the lisp code using slime? On a
local folder using Alt . to jump to the function definition is not a
problem. So I generated the TAGS file and when I jump to the function
definition (Alt . or slime-edit-definition) it opens an empty buffer
on my local hard drive which have a path like this: d:/my/linux/path/
file.lisp. I am using emacs 21.3 on Windows and slime from development
cvs, so could it be an issue only on Windows or I forgot to configure
slime+etags properly?
Thank you,
Andrew
> I wonder how you guys navigate through the lisp code using slime? On a
> local folder using Alt . to jump to the function definition is not a
> problem. So I generated the TAGS file and when I jump to the function
> definition (Alt . or slime-edit-definition) it opens an empty buffer
> on my local hard drive which have a path like this: d:/my/linux/path/
> file.lisp. I am using emacs 21.3 on Windows and slime from development
> cvs, so could it be an issue only on Windows or I forgot to configure
> slime+etags properly?
slime does not use etags for finding definitions; it communicates with
the underlying lisp image to find them. Be sure you have configured
slime properly (read the README file). If everything is set properly,
try starting slime first typing M-x slime, and then open your lisp
files and navigate with M-.
Here is an example from my .emacs file for slime (darcs version):
(add-to-list 'load-path "/home/marian/src/lisp/slime/slime") ; your
SLIME directory
(setq inferior-lisp-program "/usr/local/bin/sbcl") ; your Lisp system
(add-to-list 'load-path "/home/marian/src/lisp/slime/slime/contrib")
(add-hook 'slime-load-hook (lambda () (require 'slime-fancy)))
(require 'slime)
(slime-setup)
--
Cheers, Mariano
From: Edi Weitz
Subject: Re: jumping to lisp function definition on emacs + slime
Date:
Message-ID: <uejfwyyjn.fsf@agharta.de>
On Mon, 15 Oct 2007 18:25:15 -0000, Mariano Montone <··············@gmail.com> wrote:
> slime does not use etags for finding definitions; it communicates
> with the underlying lisp image to find them. Be sure you have
> configured slime properly (read the README file). If everything is
> set properly, try starting slime first typing M-x slime, and then
> open your lisp files and navigate with M-.
Of course, you first have to LOAD[*] the code into the image before
SLIME's M-. can find it. To the OP: This is totally different from
etags which is a /static/ process. SLIME will (usually) actually find
the definition which was used to compile the function that's currently
in the image. etags OTOH will only find what was current the last
time the TAGS file was created - which might habe been long ago.
HTH,
Edi.
[*] http://www.lispworks.com/documentation/HyperSpec/Body/f_load.htm
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Oct 15, 3:21 pm, Edi Weitz <········@agharta.de> wrote:
> On Mon, 15 Oct 2007 18:25:15 -0000, Mariano Montone <··············@gmail.com> wrote:
> > slime does not use etags for finding definitions; it communicates
> > with the underlying lisp image to find them. Be sure you have
> > configured slime properly (read the README file). If everything is
> > set properly, try starting slime first typing M-x slime, and then
> > open your lisp files and navigate with M-.
>
> Of course, you first have to LOAD[*] the code into the image before
> SLIME's M-. can find it. To the OP: This is totally different from
> etags which is a /static/ process. SLIME will (usually) actually find
> the definition which was used to compile the function that's currently
> in the image. etags OTOH will only find what was current the last
> time the TAGS file was created - which might habe been long ago.
>
> HTH,
> Edi.
>
> [*]http://www.lispworks.com/documentation/HyperSpec/Body/f_load.htm
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Yes, the code I am talking about is in the image. I compile the code,
create an image, run it with detachtty and then connect to it via
Slime. So then Slime should have all the information about the
function definitions. Still it jumps to an empty buffer. Basically it
calculates the correct path for the file only it puts "d:" before it,
must be something related to Windows...
Thank you,
Andrew
From: Thomas A. Russ
Subject: Re: jumping to lisp function definition on emacs + slime
Date:
Message-ID: <ymive963hlb.fsf@blackcat.isi.edu>
Trastabuga <·········@gmail.com> writes:
> Yes, the code I am talking about is in the image. I compile the code,
> create an image, run it with detachtty and then connect to it via
> Slime. So then Slime should have all the information about the
> function definitions. Still it jumps to an empty buffer.
Another potential problem is that you sometimes need to configure your
lisp implementation to actually save the file source information during
compilation. This may involve setting an implementation-dependent
special variable.
However, the following sentence makes it seem that this is not a problem
in your particular case.
> Basically it
> calculates the correct path for the file only it puts "d:" before it,
> must be something related to Windows...
Sounds like potentially a Windows bug. Unless the pathnames coming back
from the path computation don't specify a drive letter.
--
Thomas A. Russ, USC/Information Sciences Institute
On Oct 15, 3:21 pm, Edi Weitz <········@agharta.de> wrote:
> On Mon, 15 Oct 2007 18:25:15 -0000, Mariano Montone <··············@gmail.com> wrote:
> > slime does not use etags for finding definitions; it communicates
> > with the underlying lisp image to find them. Be sure you have
> > configured slime properly (read the README file). If everything is
> > set properly, try starting slime first typing M-x slime, and then
> > open your lisp files and navigate with M-.
>
> Of course, you first have to LOAD[*] the code into the image before
> SLIME's M-. can find it. To the OP: This is totally different from
> etags which is a /static/ process. SLIME will (usually) actually find
> the definition which was used to compile the function that's currently
> in the image. etags OTOH will only find what was current the last
> time the TAGS file was created - which might habe been long ago.
>
> HTH,
> Edi.
>
> [*]http://www.lispworks.com/documentation/HyperSpec/Body/f_load.htm
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I found why it happens. When the slime-edit-definition calls the
function (set-buffer (find-file-noselect emacs-filename t)) which in
turn calls expand-file-name the proper linux file name gets decorated
with d: prefix. Might be the emacs 21.3 problem. I'll ask in in emacs
ng.
Thank you,
Andrew
On Oct 16, 6:11 am, Trastabuga <·········@gmail.com> wrote:
> I found why it happens. When the slime-edit-definition calls the
> function (set-buffer (find-file-noselect emacs-filename t)) which in
> turn calls expand-file-name the proper linux file name gets decorated
> with d: prefix. Might be the emacs 21.3 problem. I'll ask in in emacs
> ng.
>
> Thank you,
> Andrew
You need to tell slime how to access the files in the remote machine.
See
http://common-lisp.net/project/slime/doc/html/Setting-up-pathname-translations.html
Cheers,
Carlos
On Oct 16, 2:40 am, ············@gmail.com wrote:
> On Oct 16, 6:11 am, Trastabuga <·········@gmail.com> wrote:
>
> > I found why it happens. When the slime-edit-definition calls the
> > function (set-buffer (find-file-noselect emacs-filename t)) which in
> > turn calls expand-file-name the proper linux file name gets decorated
> > with d: prefix. Might be the emacs 21.3 problem. I'll ask in in emacs
> > ng.
>
> > Thank you,
> > Andrew
>
> You need to tell slime how to access the files in the remote machine.
> Seehttp://common-lisp.net/project/slime/doc/html/Setting-up-pathname-tra...
>
> Cheers,
> Carlos
Thank you, Carlos. That was exactly what I needed!
Andrew