Currently it doesn’t

I think we could try to make it bb-compatible though, I think there's ways to do it, if @U06B73YQJ would be open to it

Looks interesting, which implications/changes this can have on promesa?, I mean I'm not aware right now of what changes I need to do on promesa for make it compatible with babashka

@U06B73YQJ I know :) It's mostly these deftype things I think: https://github.com/funcool/promesa/blob/f1c459b94fba62b6b10a7cd14aa25aef5ddd31cb/src/promesa/util.cljc#L37 I can have a look at this and make a proposal. Since promesa is already .cljc it's hopefully not too hard to add some :bb branches.

I'll have a go at it, might be a nice chore for long flight next week

@U06B73YQJ

#?(:clj
   (extend-protocol clojure.core/Inst
     Duration
     (inst-ms* [v] (.toMillis ^Duration v))))

Hmm, I think you are right, i will add it to my todo tasks for promesa, thanks

I rely mostly on clojure-lsp for jump-to-definition, as it supports more than just vars (e.g. also locals). What does CIDER implement for jump to definition?

https://github.com/clojure-emacs/cider/issues/3456#issuecomment-1713399534 it's in cider-nrepl, not base nREPL

yeah, I've tried to make the babashka nREPL implementation work with cider middleware, but it's a big headache as cider middleware relies on the most gory hacks ;)

Yeah it seems like a tough integration partner

You can just use a JVM repl to develop your bb script though. Use bb print-deps to print out a deps.edn map and then just use JVM CIDER and occassionally run your script with bb to check if it still works with bb

(as also exemplified in @U5H74UNSF’s talk at bb-conf!)

I had forgotten MK's trick from the conf

Cool, I'll try that. Thanks Michiel!

you can maybe even write some elisp to add -Sdeps $(bb print-deps) to the CIDER clojure-cli arguments automatically

I'm using a JVM REPL as a workaround. That's nice because it provides auto-complete, too. At the same time, I looked into getting this implemented in CIDER. The maintainers there say that bb is not returning the correct data on defined vars — https://github.com/clojure-emacs/cider/issues/3456#issuecomment-1715255074 is this a known bug or TODO in babashka-nrepl?

This bit of code is used to look up metadata for the info/lookup ops:

:line 1, :column 1 yeah. writing it up now

could you also try this when loading the code through a file, e.g. by executing (load-file "...") or (require '[] :reload) instead of directly evaluating it? the metadata might be reset because it goes through the REPL

https://github.com/babashka/babashka.nrepl/issues/65

do you mean from a command-line bb repl?

no, from your REPL

I think a thing like this might be happening. This is in JVM Clojure, but the behavior is the same in bb:

Clojure 1.10.3
user=> ((juxt :file :line :column) (meta #'inc))
["clojure/core.clj" 924 1]
user=> (load-string "(in-ns 'clojure.core) (clojure.core/defn inc [x] (clojure.core/+ x 1))")
#'clojure.core/inc
user=> ((juxt :file :line :column) (meta #'inc))
["NO_SOURCE_FILE" 1 23]

i think you're right

hot diggity it's like you're psychic

So...I don't quite understand what this means 😄 Where is this info getting lost, and how can we make it right?

Well my question is rather: why doesn’t this happen with nREPL, this is standard Clojure behavior :) how does it work with inf-clojure?

Maybe @U45T93RA6 has some insight? 🙂

I guess it works because of these hacks :) https://github.com/nrepl/nrepl/blob/5839006c5f522fd5e6cf2adbcc5b59e4bd0677dd/src/clojure/nrepl/middleware/interruptible_eval.clj#L28-L40

I bet navigation doesn't work with inf-clojure for vars defined per form

I think we could fix this by adding an option to edamame to add an additional line + offset to the metadata or so

which would be picked up here: https://github.com/babashka/babashka.nrepl/blob/c6c3553404f424ff5c591cffe24254f01cc2f92a/src/babashka/nrepl/impl/server.clj#L105

or actually we could manipulate the form there I guess by adding the appropriate line + column to the the metadata ourselves in that spot

that would just be a local fix without changes in other spots, might be good

would not work for evaluating nested forms e.g. in a do though, so maybe not optimal

I'm not sure that you assessment that it's standard Clojure behavior is correct In the very example you share, one can appreciate that ((juxt :file :line :column) (meta #'inc)) returns the right data for the original, non-monkey patched code. I'm sure that one can load new files while preserving meaningful metadata and no hacks. For example, fire up a bare clj , and perform (load-file "a.clj") where a.clj is:

(ns a)

(defn foo []
  )

(defn bar []
  )

> (meta #'a/bar)
{:arglists ([]), :line 6, :column 1, :file "/Users/vemv/a.clj", :name bar, :ns #object[clojure.lang.Namespace 0x74fef3f7 "a"]}

You also hint, accurately: > could you also try this when loading the code through a file, e.g. by executing (load-file "...") or (require '[] :reload) instead of directly evaluating it? the metadata might be reset because it goes through the REPL it appears you didn't persevere through this line of investigation? Generally, most code is defined through require, so ~90%+ of cases of jump-to-definition should work. Is that not the case @U05092LD5?

Code defined through require and load-file should work as is, but the "monkey patching" as you call it, i.e. evaluating a function form by form and not file by file results in the "standard Clojure" behavior I showed (using a JVM Clojure REPL). nREPL works around this by patching the LispReader using Java reflection and setting the line and column before reading the form from a string.

> Generally, most code is defined through require, so ~90%+ of cases of jump-to-definition should work. Is that not the case @U05092LD5? I do not believe it is the case but – and please forgive my profound ignorance — it's not clear to me which 90% you're referring to. It doesn't work for any of the completely normal cases I use it for, which are in all respects (relevant to my understanding) identical to what I've described in each ticket.

https://github.com/babashka/babashka.nrepl/issues/65 says "for all locally-defined vars" That's the "10% case" for me - code you've evaluated by hand. Does clojure.core or any third party lib work for you?

clojure.core doesn't work since those vars are built-ins in bb, there is no source location for those

Code I've evaluated by hand does not work, clojure.core does not work, clojure.string does not work, third party libs included by babashka do not work, third party libs included as explicit dependencies by bb.edn do not work. Jump to definition works for none of this:

(ns mvp
  (:require [clojure.string :as string]
            [clj-yaml.core :as yaml]
            [camel-snake-kebab.core :as csk]))

(def foo 1)

foo

inc

string/re-quote-replacement

yaml/generate-stream

csk/->Camel_Snake_Case

> third party libs included as explicit dependencies by bb.edn do not work I expected that to work honestly

but perhaps the csk example isn't great since those vars are defined by macros?

what do you get for (meta #'csk/->Camel_Snake_Case)?

{:name ->Camel_Snake_Case, :ns #object[sci.lang.Namespace 0x1d941969 "camel-snake-kebab.core"], :file "camel_snake_kebab/core.cljc", :declared true, :line 50, :column 1, :arglists ([s__302__auto__ & rest__303__auto__])}

ok, that's an example that imo should work

what does the info/lookup thing do there?

> Code I've evaluated by hand does not work, clojure.core does not work, clojure.string does not work, third party libs included by babashka do not work, third party libs included as explicit dependencies by bb.edn do not work. It looks to me that https://github.com/babashka/babashka.nrepl/issues/65 could be updated then, it only says 'locally' I'd also suggest making very clear that you're using load-file (CIDER offers M-x cider-eval-buffer , which uses the standard load-file nREPL op) Also, please include *nrepl-messages* logs for the specific bb nrepl responses that return a line, so that we can see if line 1 or 50 is being returned

xref--not-found-error: No definitions found for: csk/->kebab-case

> It looks to me that https://github.com/babashka/babashka.nrepl/issues/65 could be updated then, it only says 'locally' I wrote both tickets specifically about locally-defined vars because the CIDER docs say that they are supported

> Also, please include *nrepl-messages*

added nrepl-messages to bb.nrepl 65

after M-x cider-eval-buffer jump-to-def works for foo (but nothing else)

I think this is the only relevant bit:

(-->
  id         "44"
  op         "info"
  session    "105d7cf5-ea34-49e7-b4d8-13d24fe8c088"
  time-stamp "2023-09-12 22:46:26.750302000"
  ns         #("mvp" 0 3 (fontified t help-echo cider--help-echo cider-locals nil cider-block-dynamic-font-lock t face font-lock-type-face))
  sym        "csk/->kebab-case"
)
(<--
  id           "44"
  session      "105d7cf5-ea34-49e7-b4d8-13d24fe8c088"
  time-stamp   "2023-09-12 22:46:26.755712000"
  arglists-str "[s__302__auto__ & rest__303__auto__]"
  file         "camel_snake_kebab/core.cljc"
  line         54
  name         "->kebab-case"
  ns           "camel-snake-kebab.core"
  status       ("done")
)

what is the similar response in a JVM REPL without cider nrepl?

when it would work

perhaps some jar:// stuff?

gonna look back here tomorrow. it would be helpful if you could post the expected nREPL responses as well.

ok thanks for your help, will spin up a JVM REPL and report

first i'll have to dig out the instructions on starting it up without cider-nrepl automatically

probably easiest to just start one via a -main function on the command line and then use cider-connect?