VIM and Tmux here for all the things. Editors I’ve used before: emacs, intellij, atom, vscode. Never happier now that I’ve become more comfortable with VIM. https://vim-adventures.com/ was a good help in getting up to speed too 
3 Likes
vim + i3
Moving between i3 windows with vim like key patterns.
In vim everything turned off:
No line numbers, no tabs, only the one file open.
Not sure if this is the best setup but I’m stuck with this cause everything else is breaking the flow.
It is so great to see how many of us are there and I would not say still but already 
My workflow depends totally on neovim (using lua heavily and waaaay too bloated vimscript) integrating to tmux with things like system("tmux send-keys....'you get the idea'")
NERDTree, lots of Tim Pope’s plugins (Fugitive, vim-surround,…) fuzzy-vim
my big issue is screen redrawing I just need to minimize remaximize my screen whenever I switch a tmux window and that on iterm2 as well as gnome-terminal, I just did not see anybody having this problem so it’s probably a little bit OT 
2 Likes
I’ve never had this problem on iTerm2 but I have redrawing problem s often enough. If it’s just Vim, :redraw! always does the trick which you can just make a mapping for (or add :redraw! at the end of a commonly use mapping, like after save).
What do you like about Vim over Emacs? I ask because I’ve known people who have made the switch from Vim to Emacs and seem happier and there are some things about Emacs that seem attractive over Vim.
It’s interesting to see all the nvim users. I used nvim briefly around when it came about but switched back to Vim8 once it came out. What are the reasons people prefer nvim? The LSP certainly seems promising. I also found it kind of shitty how Bram refused the jobs PR and then just implemented it himself when people started using nvim. Maybe he good reason? I dunno. He’s absolutely allowed to do what he wants but I still thought it was still a little lame.
I switched to nvim around 0.2, so about 4 years ago now. There’s a few reasons why I have stuck with neovim over vim
- community based development model. I don’t like the fact that Bram must agree a feature is good before it’s even considered. See terminal, async jobs, floating windows, etc.
- standard xdg home based config. Not a massive deal but it makes everything easier to deal with and more cohesive.
- lua scripting. I don’t write a ton of vim script stuff but when I do it’s much nicer to work in lua.
There’s other benefits too, like saner defaults and dropping a ton of legacy stuff which just slowed down development, but most of the other changes affect neovim developers more than they affect me.
Basically for me it boils down to the fact that there’s no downsides to picking neovim over vim and plenty of upsides.
2 Likes
For sure! I’ve used vi for so many years (decades really) my fingers just know what to do. I’ve tried other editors but always return to vi 
1 Like
I jump back in there from time to time. It’s pretty nice at this point. My issue is I’m using the vscode elixir-ls extension. For whatever reason, my cpu spikes to 300-500% with about every action so it’s just unusable. I haven’t had a chance to dig in so don’t know if it is something unique to my machine or not. I haven’t seen the same issue testing in vscode with the same extension though. Otherwise, I’d probably try to make it my daily driver. It’s native (fast), real vim, and has ever growing support for both viml and vscode extensions.
Thanks for the feedback. I like the project for the reasons you mention but haven’t been able to set it up correctly because I never used vscode so it will take some time to understand how to configure it properly or at least how I have me current neovim setup. Best regards,
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.
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 Like
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 Likes
I just purchased it out of curiosity! I’m waiting for VimL support before trying it out more 
1 Like
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
3 Likes
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 Like
Made the silly mistake of switching from Vim to VSCode about a year ago. Back to Vim again and never going back.
I learnt loads about setting up Vim from this guy → https://www.youtube.com/channel/UC8ENHE5xdFSwx71u3fDH5Xw
2 Likes
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…)
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.
