Fork me on GitHub
#vim
<
2018-12-11
>
hkupty17:12:24

Looks like most of you don't know acid.nvim. I probably did a poor job advertising it. https://github.com/clojure-vim/acid.nvim Acid was created by me when I was painfully doing clojure with vim-fireplace because of all the slowness and synchronicity issues. It was one of the first neovim plugins written using the remote plugin architecture and it was heavily inspired in deoplete (which turned out to be a bad idea). Now I see it in a state where it is difficult to extend as it has a complex architecture and tries to fill a huge gap between nrepl and the editor. My idea is to build something way less complex by not trying to solve all problems, but providing primitives that could allow people to build stuff suitable for their workflows. This is the same approach I took with iron.nvim (https://github.com/vigemus/iron.nvim/) when I refactored it to lua and what is guiding the design of impromptu.nvim (https://github.com/vigemus/impromptu.nvim/). All of those are lua-based now and this allows an unmatched level of composability in the neovim side. This is precisely what I want to achieve with acid. If you're interested, please join in by testing or sending pull-requests. I'd be much happy 😄

🎉 8
dave18:12:20

@ingvij thanks for making acid.nvim! it's been on my radar for a good long while now. i just had some initial difficulty setting it up to try it (this was a long time ago... i don't remember what the issues were) and so i've been quietly waiting for adoption to pick up / kinks to be hammered out it sounds like things are rolling along great -- i'll probably try it again soon! i'm at a place where i can't tolerate vim-fireplace anymore and i'm looking for something better

dave18:12:45

i'm enjoying vim-iced (performance-wise, it smokes fireplace! no pun intended), but it's not without its rough edges

hkupty22:12:05

I believe most of the hassle in the early days were regarding remote plugin issues and setup/bootstrapping. Most of it is fixed but that never felt correct to me. The Lua version will be lighter in this sense and I expect to be able to provide saner ways to set up and customise it. Also, I'll focus on the nrepl operations and allow the handling of the result to be dealt by custom code more easily. That'd probably allow better extensibility and integration with other existing workflows.