Fork me on GitHub
#vim
<
2017-07-07
>
dominicm12:07:37

Is it snapshot?

dominicm12:07:23

Something tells me it's not been deployed to clojars 😛.

hkupty12:07:40

Sorry about that... Couldn't do it yet..

hkupty12:07:34

You can clone and lein install it..

dominicm13:07:19

had a thought about neovim-client the other day. What if vim plugins took a "blob" of neovim client (concat all the nses together with a unique prefix to the ns) & sent it to the running repl when they started up. And then instructed it to look at the unix socket that neovim automatically starts, or some other way of opening the msgpack connection. That way there's no slow jvm startup (just uses the existing jvm), but you get to do everything in Clojure (yay!). This template could automate the work if we figure it out. Just gotta do the figuring out part 😉. Unrepl can produce a blob.

hkupty13:07:31

Not really fan of having several separate plugins running in the same process...

dominicm13:07:43

How do you mean?

hkupty14:07:54

> concat all the nses together with a unique prefix to the ns Which nses? Once for each plugin using the neovim-client or once for all? > sent it to the running repl when they started up This has the additional problem of having to star nvim at a folder which already has a repl open..

dominicm14:07:37

Once for each plugin using neovim-client. But theoretically you could do once for all. I think the former is better (npm-style deps ftw!). Is that true? I figured you could just hot load your plugin in on first command / on connection / on missing namespace failure.

hkupty14:07:06

Maybe we can, but then we're just postponing the load to happen for the first time a command is called, but multiplying it for each separate repl that is open. Also, we end up having several different plugins running on the same repl instance/process, which can lead to a bug in one plugin degrading all other plugins sharing the same process.. Additionally, we're biasing clojure plugins to be used only by clojure developers, since we're requiring a repl to be open... I'm not sure we want that...

dominicm14:07:42

True. Maybe it should be possible to infect or to rise from the dead (vimpire?)

dominicm14:07:35

for a slow startup plugin to spread to an existing host is a pretty powerful tool I think :thinking_face: I agree we shouldn't require it to be that way. It's a nice thing to support though.

hkupty14:07:42

Injecting the clojure code and having an async frontend is a nice alternative to rpc

hkupty14:07:38

We can add support to acid, ice and vimpire..

dominicm14:07:12

I mentioned vimpire because I was making vampire references, not because I'm excited about it necessarily (just ftr)

hkupty14:07:28

Well, it does the trick asynchronously, doesn't it?

dominicm14:07:03

Good question, I'm not sure

hkupty14:07:56

Maybe we can stick to acid and ice which are those we maintain...

hkupty14:07:47

Wasn't iced moved to clojure-vim?

mikepjb14:07:31

You’re welcome to include it, I’d very much like to have a clojurescript solution where there is no need to npm external dependencies though

mikepjb14:07:23

it feels very tricky to have a ‘nice’ solution where I’d like a nvim plugin to be a. setup like a regular vim plugin e.g :PlugInstall and b. written in clojure(script)

dominicm14:07:47

did you check out nvim-parinfer?

mikepjb14:07:16

not recently

dominicm14:07:38

it's written in clojurescript & is regular plugin

mikepjb14:07:46

I am looking at it now, I’m loving how well laid out the README is

mikepjb14:07:25

the installation is relatively simple

mikepjb14:07:47

I am fairly sure you still need to install the ‘neovim’ npm package though

mikepjb14:07:54

perhaps this is a missed prerequisite?

mikepjb14:07:51

It’s not the end of the world, it just bugs me that there is so much setup required to get a plugin to work

dominicm15:07:31

You install the node-host plugin and do npm install in it's directory. That's it.

mikepjb15:07:19

That’s true, I still feel it is so clunky compared to vim-fireplace

dominicm15:07:13

I think a small golang shim with vimscript or lua driving it is the only/best way to have something lightweight

dominicm15:07:19

s/shim/binary

mikepjb15:07:50

yes I’m liking that solution more and more

dominicm15:07:04

clojure-check is the prior art on that 😉

dominicm15:07:16

and fzf.vim too I guess

mikepjb15:07:25

I was about to say haha

mikepjb15:07:01

it’s a general pain, I usually recommend atom/protorepl for new developers as a bulletproof way to setup a clojure environment but even that will fail because tools.namespace is missing if you’re on a machine that has never run clojure before

mikepjb15:07:14

or at least that is my experience!

dominicm15:07:43

Didn't have the protorepl issue with TNS. But /shrug

dominicm15:07:54

editors are hard 🙂

mikepjb15:07:47

as are plugins written in external languages!

mikepjb15:07:22

interesting to see proto-repl is written in coffeescript and clojurescript?!?

mikepjb15:07:58

nice to see that the package.json deps are gathered without an extra step from the user too

mikepjb15:07:36

I don’t know the first thing about node-host or <external_language>-hosts in general for neovim but it would be nice if we could include the npm install call

mikepjb15:07:14

even if it was just to include the ‘neovim’ package

mikepjb15:07:44

like cider middleware, load up the package you need to communicate with neovim for the language host that you’re using

mikepjb13:07:08

ah thanks @ingvij it’s been a while since I’ve used a lein template

hkupty13:07:29

No problem! 😄

jebberjeb18:07:13

interesting discussion

dominicm19:07:14

@jebberjeb I'be been thinking about Stu's talk quite a bit, inspiring some re-thinking of how I think about repl integrations