One might argue that evaluating or loading a compiled expression inside an emacs buffer visiting a file should be as close as possible to what happens when the file is loading.
To this end what do you think about wrapping forms evaluated with slime-eval-defun and friends with
(let* ((*load-pathname* <emacs (buffer-file-name)>) (*load-truename* (and (probe-file *load-pathname*) (truename *load-pathname*)000 <expression> )
or something like it.
For example, evaluating an asdf defsystem form depends on this...
-Alan
Alan Ruttenberg alanralanr@comcast.net writes:
One might argue that evaluating or loading a compiled expression inside an emacs buffer visiting a file should be as close as possible to what happens when the file is loading.
To this end what do you think about wrapping forms evaluated with slime-eval-defun and friends with
Do you need this often?
This is a bit too DWIMish for my taste and I think slime-load-file should be used in such situations.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Alan Ruttenberg alanralanr@comcast.net writes:
One might argue that evaluating or loading a compiled expression inside an emacs buffer visiting a file should be as close as possible to what happens when the file is loading.
Do you need this often?
This is a bit too DWIMish for my taste and I think slime-load-file should be used in such situations.
I'm not so sure: we already DWIM as far as setting *package* from the file's package is concerned, and I don't think anyone's going to argue that that's a bad thing: is it so much more wrong to set *compile-file-pathname*?
I often write code that accesses files in the same directory as the source (or a directory with a fixed relation to the source code). Because I always use systems to load code, *default-pathname-defaults* is not necessarily the right place, so I like to use *load-pathname* to get the right place. This doesn't currently work if I C-c C-c the relevant form.
(There's also a possibility that setting *cfp* during function compilation makes the implementation remember where the function came from such that M-. is more likely to continue working afterwards. That depends on the implementation, obviously.)
-dan
Daniel Barlow dan@telent.net writes:
Do you need this often?
This is a bit too DWIMish for my taste and I think slime-load-file should be used in such situations.
I'm not so sure: we already DWIM as far as setting *package* from the file's package is concerned, and I don't think anyone's going to argue that that's a bad thing: is it so much more wrong to set *compile-file-pathname*?
We should shadow as few variables as possible, especially in important commands like eval-defun and eval-last-expression. I think *load-{true,path}name* are used relatively rarely and only in code that is supposed to be executed at load time. Binding these variables in eval commands doesn't feel right to me. Setting *compile-file-pathname* even more so. The inconvenience of using slime-load-file in these situations is IMO justified.
Of course, this is just my opinion. If you think it is a good idea, change the code and let's try it for some time.
(There's also a possibility that setting *cfp* during function compilation makes the implementation remember where the function came from such that M-. is more likely to continue working afterwards. That depends on the implementation, obviously.)
I'd be surprised if *compile-file-pathname* where not shadowed by COMPILE or COMPILE-FILE.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
We should shadow as few variables as possible, especially in important commands like eval-defun and eval-last-expression. I think *load-{true,path}name* are used relatively rarely and only in code that is supposed to be executed at load time. Binding these variables in eval commands doesn't feel right to me. Setting *compile-file-pathname* even more so. The inconvenience of using slime-load-file in these situations is IMO justified.
The important question is "When would binding these variables *harm* anyone?".
-
Alan Ruttenberg -
Daniel Barlow -
Helmut Eller -
Rahul Jain