I don’t really use vscode either, but you can install the elixir-ls plugin within the Onivim UI. Other than that, all the settings I’ve changed (keybindings, viml, etc) have been vim-related rather than vscode-related.
baldwindavid
jc00ke
Same here!
I use yadm to manage my dotfiles of which this is the relevant Neovim config. I use CoC for the LSP, though I’m curious to hear how it performs compared to Neovim’s built-in LSP client.
Got any notes to compare to CoC? I do appreciate all the other CoC plugins.
While I stick to doing everything in Alacritty, I use Neovim’s terminal over tmux. I used tmux as a daily driver years ago but at some point it stopped being useful.
Exactly! The LSP is great, and I miss it for projects that use old versions of Elixir, but I do hope it can someday be more robust.
What I miss most is Tabnine. My jaw has literally dropped at times at how much it correctly predicts. It doesn’t play well with LSP though, even with coc-tabnine (at least the last time I tried) and I’m not happy with the changes to the license model after it was acquired by Codata. I had bought a one-time pro license for $50 or $100 and they don’t honor it anymore. 
1
dbern
Got any notes to compare to CoC?
neovim-lsp is still early, so these notes aren’t future-proof:
- neovim-lsp feels faster and I assume it’s because it doesn’t require nodejs to handle processes. I have no benchmarks.
- It’s configured in Lua, which is quite different from vimscript configuration that you might be used to.
- It’s less-friendly about auto-installing language servers. I think this is reasonable though.
- Even though CoC has been around for a while and therefore has some more compatibility, the plugins were usually small forks of the vscode plugin adjusted to work with CoC. I think I’d rather not have that tighter coupling with vscode.
- In neovim-lsp, it asks the lsp for capabilities and then you configure those capabilities for your vim. This let’s me customize my vim to my liking from the start.
- in CoC, you have a vscode-oriented json to inform what the lsp capabilities are and CoC will use them. This doesn’t require me to configure my neovim according to the capabilities of the lsp, so it’s easier but maybe harder to configure to my specific liking. It’s a trade-off.
2
connorlay
I just purchased it out of curiosity! I’m waiting for VimL support before trying it out more 
1
soup
Another nvim user here, after using vim for many years.
I really liked nvims goal of
- being an embedded text engine (so now we have real nvim in ffx or vscode, not just “vim emulation” modes)
- more open development
- replacing viml with lua
I loathe vimscript, while I only find some parts of Lua mildy distasteful. I have a few plugins such as a zettelkasten/evergreen/nv system which I could never write in Vimscript (not fast enough, had/has no async and not nice enough to write to make it work). I also wrote lush.nvim which I can’t imagine ever working in viml because it’s so slow and frustrating to express in. Sure I could use python/ruby bridges but then you’re shipping an extra runtime dependency, with all the baggage that comes with that.
I was really disappointed to see Vim9 try and make vimscript9/2/ng a thing instead of just picking an existing language to integrate.
FYI to Elixirites, there is an (another) Elixir Treesitter project that @Tuxified is working on, that might benefit from more exposure and helpers. I have only had a small amount of time to help myself, but we as a community could benefit greatly from a good TS module.
Hopefully he doesn’t mind the announce.
GitHub - Tuxified/tree-sitter-elixir: Tree Sitter grammar for Elixir · GitHub
3
sodapopcan
Ya, the more open development is a big thing (I often wonder what will happen to Vim once Bram passes on).
I personally don’t hate viml and actually kind of enjoy it in a way. It’s absolutely a case of Stockholm Syndrome and I have never tried to write a plugin any other way. I would also never deign to call it a good language, but for me it works well as a DSL for its intended purpose (kinda like JavaScript :trollface:).
This thread is inspiring me to give nvim another try, though. Also, lush.nvim looks really nice! I love tweaking my colour scheme (at some point I’d like to “release” it as its own package) so this is very much up my alley.
1
stuartmackey
Made the silly mistake of switching from Vim to VSCode about a year ago. Back to Vim again and never going back.
https://github.com/stuartmackey/config_manager
I learnt loads about setting up Vim from this guy → https://www.youtube.com/channel/UC8ENHE5xdFSwx71u3fDH5Xw
2
soup
I would say give it a shot. You don’t really have anything to lose, but do have something to gain. I’ve never seen a vim-only plugin that I really wanted but there are nvim only stuff.
You might also find your more likely to write your own plugins when you have access to real libraries (https://luarocks.org and libuv built in).
If maybe vim9 script becomes super popular, resulting in a whole bunch of new super cool vim9 only plugins, there is already a toy/meme project to jit vim9 that would rapidly become a not-meme if there was a real reason for it to exist.
(Also I believe the vim9->lua jit out performs native vim9…)
0
sodapopcan
Oh I certainly write my own plugins and never feel to held back. I’ve only released a couple, though (twiggy.vim and ifionly.vim). When I install nvim I’ll give lua a shot, probably use lush.nvim as a starting point to learn! My hesitation comes from wanting to stay compatible and not leave Vim users in the dark, but I’ll certainly give it a shot.
0
