Hey, this reminds me. I have a need for an nREPL client that is thin and super light-weight, for CLI use. Well, not exactly for CLI use, but for use by an editor that is heavily bought into the idea of small tools and UNIX. Which means, I think, that the client needs to maintain persistent connection, by forking and forwarding.
I started hacking on a tool a few weeks ago (called rep
, because it doesn't l
). But never got it useful.
@eraserhd python? 😄
Vim loads python dynamically, so it can keep the connection open, I thought. Kakoune won't do that.
But a python cli would work?
Python startup time is acceptable, IIRC.
alternatively, use go, I had success with that too.
I started hacking in Rust, 'cause I like it so much.
A bencode decoder can be written quite easily, I encourage you to continue with that path
OK. It's on hold for a couple weeks. I was actually wondering if anybody had done something like this.
I thought about it, but I came to the conclusion that such a thing would have to end up editor-specific, and wouldn't be an effective use of my time because of nvim's remote plugins.
You end up needing to put things in a form that your editor can richly inspect.
Hmm, that's not my plan. What does it need to richly inspect?
@eraserhd e.g. key-values.
So, in terms of the REPL window, it will write, pre-formatted to a fifo. But the client rep
command will return EDN or some such structured output.
(Kakoune can follow a fifo.)
More obvious example, if you want to have something like quickfix populated by info about a var, you'll want to convert to a vim structure in order to setqflist()
If you can parse edn in kak, then you have way more power than me 🙂
I guess I can't, actually. But adding result format options is not too bad.
I guess everything probably has json support now, I don't think vim did at the time I was looking at this