[slime-devel] * load-pathname*, *load-truename*
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 -- http://web.metacircles.com/ - Open Source software development and support
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?". -- Rahul Jain rjain@nyct.net Professional Software Developer, Amateur Quantum Mechanicist
participants (4)
-
Alan Ruttenberg -
Daniel Barlow -
Helmut Eller -
Rahul Jain