by the way @kotarak has made https://github.com/kotarak/vimpire

@kotarak Planning to implement unrepl on it?

Yep

Awesome 😄. Lots of "competition" in this space now.

There is? I'm not uptodate there.

https://github.com/clojure-vim/neovim-client is for talking to socket repl also. https://github.com/clojure-vim/acid.nvim does a lot with the nREPL.

clojure-vim has become a bit of organization for the vim/clojure group.

Also vim-fireplace of course.

The neovim stuff has many moving parts....

@kotarak Not sure I follow?

I see there python/pip and such things. That's a pain on the company machine.

@kotarak For acid, there is python/pip. if_python has been moved to being an external module (not compiled into vim).

This allows extensions to be written in any language though. For example https://github.com/clojure-vim/clj-refactor.nvim and https://github.com/clojure-vim/nvim-parinfer.js are written in cljs

There I read something about node.js IIRC. That's what I meant with moving parts. Just an observation.

You can definitely take on more moving parts. Plain ol' vim can in much the same way really (see YCM) anything that requires a language ecosystem to work will have those moving parts. It's up to plugin authors to try minimize those where they can.

I'm sort of coming round to the idea of Go/Rust/(Chicken?) being the ideal languages for writing async components of Vim plugins. Just because they're a cross platform statically compiled binary with minimal fluff.

everything is better with ice you guys 😉

https://github.com/michaelbruce/ice.nvim

we have lots of competition

That is great!

Ruby now too? 😆 There's nothing if not choice

@mikepjb Are you going for the 3 letter thing?

😉

haha yeah I tried in anger to write the project in clojurescript on node but it proved too difficult

I know ruby so there is much less of a barrier testing everything/working with sockets etcetc

no vimscript so far too haha 100% ruby 😉

and yes @dominicm I am

Because of node? Cljs? Or node-host?

> no vimscript so far too haha 100% ruby And that is the beauty of neovim...

mixed bag - 1. my own unfamiliarity with node, 2. having issues running integration tests that run on node against a running repl and yes finally 3. node-host combined with having to compile the project each time to use in neovim made development more difficult

2 is easily fixed. Don't write tests 😁

No tests means they don't break. Easy.

oh you 😉

it’s tempting to rewrite and provide an alternative to node-host

@kotarak the biggest barrier to a pure vimscript unrepl client I can see is trying to parse edn in vimscript. Or do you have a solution to that?

I really like the idea of writing clojure plugins in clojure but have found it to be more trouble than it’s worth

I tip my hat to @snoe!

@mikepjb once you have ice.nvim to a good level, ping me & I'll integrate NCM with ice.nvim

Deoplete might be a bit harder, but potentially doable.

NCM?

uh, basically I'll get it into async-clj-omni 🙂

right!

will do 😊

The major problem I have with writing the clojure problem in clojure is having to fire up a jvm for the plugin...

This might make things slower than they should..

@ingvij Well, clojurescript. On node.

> node. still a problem for me...

(but that goes down to personal preferences, not really technological ones..)

Ah.

Yeah, I think we're going to have a chaos period in Neovim for a while. With Ruby/Go/Python/Node/Rust/Haskell(1 rogue plugin)/Lua all competing to have you install their ecosystems.

Then one or two will win out (e.g. Ruby & Node), and then the transitions between languages will be slower, with migrations happening slowly as certain languages show ease to set up within Vim.

> (e.g. Ruby & Node) I'd call it a nightmare..

Don't mind me, I'm just being picky..

Though, speaking of "ease to setup", I think node wins over python & ruby due to how they handle dependencies. Python is global (without virtualenvs, but they become messy, as you must have a virtualenv for all of vim). Ruby is… I've never figured it out. Similar to python though. node_modules is pretty great for "this is local. It will not touch anything else"

ruby wins for me only purely because I’ve used it in full time work for years

I see some value with compiled plugins (such as those built with rust, go or haskell).. They're literally standalone and it seems to me that they are the least intrusive..

would agree that node seems to be the best choice - clojurescript & ease to setup are big pros

which makes rewriting node-host in clojurescript so tempting… 😏

@ingvij I agree. I think that's actually what makes fzf so simple to use.

I've been experimenting with Go as an nrepl client in https://github.com/SevereOverfl0w/clojure-check/ which is working pretty well.

:thinking_face:

Sounds interesting

fzf's installer script goes over to the latest builds & just fetches the binary for the right platform (out of about 10 or so)

also writing in clojurescript grants more experience with clojure rather than learning another language to solve your current languages ecosystem

It's worth sticking with figuring out. 2017 is the year of clojurescript on node 😄