Jumping to a library definition opens a file not bound to any CIDER session

[alexander-yakushev]

I have a workflow when I M-. into a function defined by a dependency. This opens a code buffer from the JAR, which I then can edit and evaluate forms to make some quick runtime-only hacks to the library. Now, with the connection handling rewrite, this changed – a buffer opened by M-. is not bound to a CIDER session (the message in the minibuffer is No linked CIDER sessions when I try to evaluate anything).

The question is whether it would be sensible to propagate the current CIDER connection to any buffers opened by Go to definition.

Meanwhile, I'm fine manually linking the buffer to the session for this particular usecase.

;; CIDER 0.18.0snapshot (package: 20180808.1857), nREPL 0.2.13
;; Clojure 1.9.0, Java 1.8.0_102

[vspinu]

Something along those lines should be definitely implemented, but I am not sure atm what should be the right approach. Automatically linking buffers is the simplest of all but would create unnecessary noise for link management, specifically all those links will show in the session browser.

Maybe custom jar context could be a way to go here. That is, don't associate with a buffer but with the whole jar. Similarly if a goto brings you into a dependency project it should also be automatically linked. And of course this behavior should be customisable.

[stardiviner]

I want this implemented too. I think the whole jar library dependency is linked is better, what if you go deeper [M-.] in the opened file to another file? So the whole library should be linked.

[bbatsov]

There's however the problem of going to the source of the same library from multiple sessions. That's why I like the simple propagation of the session of whatever you invoked M-. from.

Maybe custom jar context could be a way to go here. That is, don't associate with a buffer but with the whole jar. Similarly if a goto brings you into a dependency project it should also be automatically linked. And of course this behavior should be customisable.

I like this idea. We just have to make sure the context would always switch to the last session from which a jar was accessed.

[vspinu]

I like this idea. We just have to make sure the context would always switch to the last session from which a jar was accessed.

This should happen automatically. When multiple associations are present they are disambiguated by recency.

[bbatsov]

Fine by me.

[stardiviner]

After I use sesman-link-with-project. Then I can jump around dependency definitions. But still, this is manually. Should be automatically.

[plexus]

For anyone looking for a quick fix while this gets sorted out, this does the trick

(defun plexus-clojure-extras/around-cider-find-var (fn &rest args)
  (let* ((sess (sesman-current-session 'CIDER))
         (orig-buf (current-buffer))
         (result (apply fn args)))
    (unless (eq orig-buf (current-buffer))
      (sesman-link-with-buffer (current-buffer) sess))
    result))

(advice-add #'cider-find-var :around #'plexus-clojure-extras/around-cider-find-var)

[vspinu]

Frankly, I am not happy with how jars are currently treated. Opening each file at a time is unsatisfactory for a variety of reasons. I would like to have the full archive unpacked alongside jar and jump to a file within that unpacked directory.

@bbatsov Do you have specific thoughts regarding this? Would it be ok to look at it on this occasion?

[vspinu]

Nevermind. Emacs has no built-in solutions for decmpressing the full archive, and I won't be writing one on this occasion. I will instead add a lookup for avfs indirection if available.

[bbatsov]

I never thought much about this, but I've also never had serious problems with the current approach.

[plexus]

Thanks a lot @vspinu!