With regards to doc lookup: I'm thinking of having a <localleader>d_ prefix, where _ is what you want the doc of. So like ee evals the current form, de would doc the head of your expression. In a defn somewhere you could use dr to doc the root (the defn macro). dw would doc the element under the cursor like K would normally. Doc output will appear in the log and the HUD will show it to you.

So you can ask for the doc of the symbol under your cursor, the head of your form or the head of the root form.

Or should it just be "doc thing under cursor" as usual?

I like the idea of being able to doc at an element or form level but I'm not sure if it's too specific. I like this level of specificity that allows me to ask for things without moving my cursor so much.

Personally, really gotten used to "doc things under the cursor" with K

I too am used to K, however, I can adapt if need be 🙂

Hmm food for thought then! K will be easier to implement anyway, I'll stick with that for now.

Also just wrote some checks so if your cursor is in the top right corner (by dividing your editor into four equal corners) it'll move the hud to the bottom right.

So the HUD is always on the right and tries to be at the top, unless your cursor is in that area. By giving it some extra padding (not checking if it'll exactly cover the cursor) we avoid hiding parts of a form you're interested in with results.

If you mainly edit one buffer at a time on the left of your screen you'll probably rarely see it move.

Now the HUD won't appear if you have a log buffer open with your cursor at the bottom. Since that's following along with the eval results anyway. You can however open the log, pin it to some past result by moving your cursor there and then continue to eval. The results WILL appear in the HUD since you can't see them at the bottom of the log, you're looking elsewhere!

More of my "try to do the right thing given passive input", so you just go about your business and I'll try to show you what's important without repeating in multiple place on the screen.

Feel free to try out the sourcery repo. Start an nREPL with a .nrepl-port file, open a Clojure file, eval with <localleader>ee etc.

K will do doc under cursor.

You can also eval text objects and motions with <localleader>E<motion>.

Or visual select and hit <localleader>E.

Or type into :ConjureEval ....

I really need to document 😬

https://asciinema.org/a/TTfNFZkWF6GTsRyRQil4588bI UX today

Doc isn't working with piggieback CLJS, it doesn't send the output to the right place, figwheel is probably fine.

The hud is pretty darn neat

Perhaps I missed this, but what are you using to bring up the other split to eval into?

That's the log buffer, <localleader>lv is vertical, ls is horizontal (like split and vsplit) and lt is a new tab you can close whenever. (like a fullscreen mapping)

cool, is that in conjure presently?

The log buffer?

yes - I know what the answer to this is going to be 🙂

I don't think I've used tabs ever in vim 😉

windows all the way for me!

<localleader>cl to open, cq to close and cL to toggle 😄

I like tabs for fullscreen while leaving my old windows in palce

I can just :q and pop back to what I was doing

I have <leader>wm mapped to pop the current window into a new tab, think window maximise

You know, I thought the log buffer wasn't writable, just read-only

i was wrong

Oh no! That's a core part of the design!

Just wrote a little defn in the log buffer, eval'ed the form and used it

Edit and eval away in there

It's a scratch eval buffer and a log

Yep! Can't remember which namespace it comes under, probably user?

Or cljs.user if you're in cljs

Yes

#user

JVM Conjure may be inconsistent but Lua Conjure should always be user and cljs.user.

Yeah, I use that buffer all the time. Work a lot more like a terminal REPL in Lua Conjure too

I'm looking forward to when what you have is ready for beta testing 🙂

take your time 'tho 🙂

I'm looking forward to all the bugs people find 😄

Already got people asking on twitter for other lisps support too. https://janet-lang.org/ is now on the list beside MIT Scheme and Racket.

Babashka should just work with Clojure support.

Although I think I need to improve my bencode parsing into a more streamy / buffered model to work with bb.

My initial connection resulted in errors.

@borkdude any thoughts on writing a .nrepl-port file from bb?

(awesome work btw, it's such a cool feature)

@olical What would you be using the .nrepl-port file for, can you describe the workflow? Maybe it can be solved differently with bb. I think PEZ and I also talked about this.

Oh, it's a file the nREPL server writes when it starts up. Since it starts on a random port it writes that port into the file, then things like Cider and Conjure check for it when connecting. That way you can just assume if that file exists, you can connect to it. Or try to anyway.

I think lein repl creates one too? I thought it was the convention for any CLI nREPL client to create it.

Like with propel, I create a .prepl-port file

Should've replied with a thread, oops. To make sure you get a notification, here's an @. @borkdude

@olical Babashka doesn't start an nREPL server on a random port, it also doesn't do this for the socket REPL

Ah, okay, well no problem then. With propel I made it so if you didn't specify a port it'd pick one and write to the file which ended up being nice for tooling. It's not a big deal really, I just like port files 😅

What I suggested to pez was basically (from Calva) do something like:

FREE_PORT=$(bb '(defn random-free-port [] (let [n (rand-nth (range 1000 10000))] (try (.Socket. n) (recur) (catch Exception _ n)))) (random-free-port)')
bb --nrepl-server $FREE_PORT

and then you can use (wait/wait-for-port "localhost" FREE_PORT) to wait for the server to become ready

so you can discover a free port, start the nrepl server and wait for the server to become available, all with the same tool

Janet looks neat.