Remote nrepl and nrepl jump #216

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
2 participants
Contributor

klang commented Jan 10, 2013

If emacs and clojure are running on different host types, nrepl-jump on a function defined in a resouce will fail. (nrepl is implicitly connected to a remote host)

e.g. M-. used on map should open clojure-1.4.0.jar and jump to the definition of map, instead it opens an empty buffer.

This fix checks if the resource is available locally to emacs before opening it. If it isn't, the nrepl-jump will fail in the same way as previously.

If both the local and the remote machines are used for clojure development, resources in ~/.m2 should be available on both platforms and a local load is safe to do, thereby avoiding network traffic.

I have made a simple setup here:
https://github.com/klang/repl-tests

I think it would be nice to work nrepl jump with remote server!
But it should not lookup local jar file when connect to remote server.
Because it could be defferent code between local jar and run on remove server, and that makes toruble when debbuging.

I also tried to this feature work with slime before.
It can do both 1. and 2. with Tramp-Slime plugin. But slime can't handle remote jar (zip) file well.
So that, Search failed: " clojure/core.cls$ was occured.

BTW, I think we can use same (or similar) filename translation rules used in slime1.

Contributor

klang commented Jan 11, 2013

Looking up in the local jar file was a choice. Encoding, transfering 3.4MB data (clojure-1.4.0.jar) and decoding it again takes too long time for my patience :-)

Either way, it's the path translation that goes wrong .. maybe we should have a configurable value besides looking in "the usual spots" for an acceptable resource to show. (balancing things between network traffic and correctness .. clojure-1.4.0.jar is the same regardless of where it's read from, hence my choice)

I can see that the slime filename translation rules can be used as inspiration .. I'm diving into this.

(please comment if I'm barking up the wrong tree here and fixing something that can be fixed more easily in a different way)

EDIT after a couple of hours: this whole mess might have to be solved with a nrepl-tramp extension, based on slime-tramp.
Furthermore .. connecting to a mac from a linux machine ln -s home Users in / will solve the immediate wrong path problem, but not the deeper problem: that find-file is given the wrong path to begin with.

Contributor

klang commented Jan 16, 2013

the clojure part of nrepl-jump-to-def has been changed to deliver username and LocalHost of the machine running clojure. This information is used to decide where to get the resource.

nrepl-find-resource has been modified to prefer existing local jar files over jar files on a remote host AND to prefer already opened jar files over any other instance of the file.

By and all, M-. now works as advertised.

@klang klang commented on the diff Jan 16, 2013

@@ -374,11 +402,17 @@ Uses `find-file'."
nil))
(defun nrepl-jump-to-def (var)
- "Jump to the definition of the var at point."
- (let ((form (format "((clojure.core/juxt
- (clojure.core/comp clojure.core/str clojure.java.io/resource :file)
- (clojure.core/comp clojure.core/str clojure.java.io/file :file) :line)
- (clojure.core/meta (clojure.core/ns-resolve '%s '%s)))"
+ "Jump to the definition of the var at point. Will not jump if definition is undefined"
+ (let ((form (format "(clojure.core/if-let
@klang

klang Jan 16, 2013

Contributor

Give emacs a little bit more information to work with, otherwise emacs will believe that the paths returned by clojure are local to emacs and they are not.

/Users/userA/some/path/to/jar/file is very different from /home/userB/some/path/to/jar/file and /ssh:user@host:/home/user/some/path/to/jar/file

The last path was not available to emacs at all, causing it to fail when M-. was used via an nREPL connection to a remote host.

Contributor

klang commented Mar 27, 2013

There is too much to read and understand in the above. I will try to raise the issue again, when I figure out how to express the problem more clearly.

klang closed this Mar 27, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment