I think (neo)vim has many years ahead, but also think the market overlaps with vscode. I believe that, for the average users, defaults, including a default plugin marketplace makes most of the difference.
It would be interesting to see some proper data about user editor preferences
https://trends.google.com/trends/explore?date=today%205-y&ge...
The overlap with VS Code is very helpful for Neovim too though, as Neovim integrates well with technologies and plugins intended for VS Code. My C++/Rust debugger setup comes from installing VS Code, getting it to install its debugger, and then pointing Neovim at it.
I don't think you're really meant to tweak configs much in neovim. Just get a basic config file off GitHub and then update here and there as you find stuff you like/need.
I know that sounds complex but if you're coding (which I assume many neovim users are) should be fairly straightforward
I have a hard time buying the argument against changing defaults.
I do get that the Vim editing model is hard, but that professional developers refuse using a tool because you have to change some defaults and customize it a little is too much.
It's really not that hard or time consuming to setup, for more gains than many of the courses or experiences people have put themselves through.
And it's not like it's a "vscode vs Vim" thing, I see the same argument inside the Vim community too where people refuse plugins because it's too much work, or even switch to Vim-like editors that don't have a plugin system as if it was a positive thing.
What gives? I'm sure it's not as easy as everyone just being lazy.
map("n", "<C-h>", "<C-w>h", { desc = "Go to left window", remap = true })
To understand this (and to adjust to your liking) you kind of have to learn the language you're not going to use ('gj' or <C-w>h) instead of using something easily readable like ["go","window","left"], or instead of actually pressing C-w to insert <C-w> like many (mostly GUI) apps allow
Then the time consuming part: it doesn't make it easy to resolve conlficts which inevitably arise when doing many rebinds. Also, it'd be very time consuming to learn and reference that unused binding language
Then the help is rather verbose and not intuitive (see my parent comment) (don't remember if help uses default keybinds or actual ones
Then it relies on a very barebones and not very popular language (though miles better than vimscript)
Then there are a gazillion of other things which make the perception reflect the reality pretty well
It's got to do with (broadly) accessibility / enthusiasm.
Enthusiasts are familiar with a lot more, know the domain, and so are able to navigate the intricacies. -- There's an xkcd comic which points out that you're probably under-estimating what it takes to be familiar with this stuff. https://www.explainxkcd.com/wiki/index.php/2501:_Average_Fam... -- And while it's nice to be enthusiastic about stuff, not everyone's going to have full enthusiasm for everything they do.
In terms of accessibility:
Having "bad defaults out of the box" just doesn't make sense compared to "having good defaults out of the box". If it's very unusual, or unintuitive to use, that's just added friction to get someone to learn. (And if fewer people adopting a tool leads to a smaller community).
There's plenty of stuff which isn't so hard if you know where to look.. whereas, without knowing where to look, it's confusing to navigate.
There's a communal cost to having fragmented/bespoke setups; if everyone's using pretty much the same thing, then anyone can help anyone out. -- Someone familiar with the intricacies will be able to understand the differences, but a novice might not know which bespoke thing would be best to copy.
The issue I consistently run into with my customized setup is it is hard to replicate. Deploy it to a new system always results in hours of headache. Many neovim plugins rely on node js which is a dumpster fire. Any time I update anything a plugin invariably breaks. I have to spend an hour or two troubleshooting to get my editor up and rolling again. This is a major pain in the ass.
I had tried getting into a vim about a year and a half ago, I used chris@machines LunarVim and I think that about after about a month I quit. I struggled with learning vim motions and how to configure it. Granted, I may like it more now that I know more.
But, this video got me to try neovim again and I have not switched off for a few months now. I daily drive now and it is thanks to this video. The configuration is simple to understand and a lot easier to come to grips with. The video is a little outdated in that some parts don't match with how the configuration is set up now, but it was easy to figure out how to work with it (sorry my memory isn't great on what issues I ran into, skimming through the video it seems like Packer->Lazy is one).
I've been an avid Vim/Neovim user for several years now, but I've never been able to really get into some of those pre-made configurations like LunarVim. I personally only like to add plugins for things I have identified as lacking, but I can see why a pre-made solution would be nice. However, last I looked I found the documentation rather lacking. Even getting a list of what plugins they add, or a general sense of the keybindings they've changed was difficult, not to mention the difficulty if someone was learning Vim for the first time on top of that.
> The video is a little outdated in that some parts don't match with how the configuration is set up now
This is exactly my problem any time I try and get in to Vim/Emacs/NeoVim, even when trying some pre built config like Doom Emacs, LunarVim etc. Everybody has some bespoke setup so following along from a tutorial is a fucking nightmare because inevitably something will be out of date, or they'll be using a different package for say the file browser that makes it incompatible with the one you're using that you picked up from the previous tutorial. Or they'll be using a different package manager entirely, of which a new one seems to come out every year. Or you're fucking around trying to get LSP to work again because something has broke it. Or you'll try installing some kind of manager to let you switch between the different premade versions such as Doom Emacs and SpaceMacs and that won't work properly because Doom has been updated since it was written etc. It's just a never ending torrent of pain. It's the editor equivalent of the JavaScript ecosystem where there's some new shiny half baked bullshit every week. It's so much easier to just use VSCode or Jetbrains and have a consistent and reliable experience every time.
I think that's why kickstart is good to start out with, despite the video being a little outdated it was still easy to reason with. I haven't run into those issues describe but it's probably because I'm still newer to the ecosystem.
I didn't enjoy lunarvim at all and actually quit nvim several times and was beginning to like doomemacs until I gave Astro a try. Instantly got hooked.
I recently forced myself to learn vim motions and it's been paying off pretty well. Once it clicked I found myself wanting vim motions everywhere.
I went deep and set up a neovim config, forcing myself to use neovim full time. However my new role requires me to use Intellij and I didn't want to spend hours upon hours figuring out how to replicate the java support in Neovim (and no, it isn't just installing the LSP, my work has some pretty specific intellij setup).
At this point I'm just using Intellij and VSCode with their respective vim plugins and I'm getting about 80% of the utility that I did with pure neovim. The one thing I really love about neovim is that it really forces you to keep your hands on the keyboard and you learn the keybinds very well because otherwise you just can't do the thing you wanted to! I find myself using the mouse a lot in VSCode and Intellij because they give you really handy buttons to click on.
I could probably go pure keyboard if I just sat down and learned all the various keybinds, but who has time for that?
For IntelliJ, check out what you can do with the .ideavimrc file. You can turn pretty much anything into a vim motion and it has light plugin support as well. Also makes your setup portable.
Yeah, I've been meaning to spend more time on it, but I've been switching around to different editors a lot lately, so the constant jumping around means I'm trying to keep my vim keybinds as vanilla as possible.
Biggest personal issue with VS codes vim mode is that it only works in the text editor. The beauty of vim/neovim is that the keybindings work everywhere in the UI, not just the text edit window.
Have you tried the neovim plugin instead of the regular vim one? I find they have different trade offs, but the neovim one is actually using neovim inside a vscode window and requires a neovim install.
Particularly, I’ve found the undo functionality to be far better with the neovim one, it never screws up. Holding alt and moving a line up and down can sometimes accidentally move your cursor one line higher or lower though.
I basically had to disable entire VS Code. Didn't remove it yet and keep it just in case I need to remember how crappy it's. It has some advantages over neovim though, but they don't outhweigh neovim.
Is there really any truth to the superior customizability (he calls it a Personalized Development Environment) claimed here?
VSCode extensions can change crazy stuff such as [1], and are also more numerous. I don't see much of an advantage to terminal-vim apart from performance and perhaps an inherent joy of building your own tools.
My take is that the customizability comes from the init.lua being more rightthere for you to look at and modify. LunarVim comes with a great set of plugins, but whenever I want to customize something I have to go and start digging to figure out what and where it's happening, how to adjust around it, etc...
The tl;dw is that the term 'PDE' means the tool requires some work in order to personalise, but because neovim exposes a robust API that work is fun and rewarding. Additionally, he makes the point that because you configure it in the same language as you script it with (lua), you have much greater control over how all the pieces fit together.
My only gripe is his requirement that the majority of users must make use of the scripting system in order for the program to be considered a PDE. If only 1% of all IntelliJ users ever use the Program Structure Interface or the powerful Live-Templating system, that's still a respectable number in total. And it also doesn't mean IntelliJ is less personalizable.
Right now I'm building a vscode plugin that renders a webpage directly in the editor. I'm absolutely sure that the vim/neovim proponents are right about how much faster you can be with vim motions, but it'll never match the versatility of vscode primarily because it's built on top of web technologies.
For me the most common reason for rendering a web page in the editor is to have a side by side view of the markdown document I’m editing. I like using mark down to write basic documentation and tutorials and not having to have a render-> open in the browser step just makes that smoother. Yes I could have two windows side by side and yes I could have file events and watch for the markdown to be saved and kick off a render and kick off the browser refresh… but I can also just open a second pane in VSCode and let it do all of that for me.
I never really considered using (Neo-)Vim (granted, I did use Emacs for years) but the other day I watched the "0 to LSP in 30min" video[0] by ThePrimeagen and I now I really want to give it a shot!
I spend a lot time inside vim/neovim on daily basis. I do have vscode open as well but it's mostly for referencing or file exploration on repos I'm not familiar with.
Building a mental and muscle memory is tough but it requires grinding. You have to put in the time! It took me months!
My biggest mistake was starting and playing around with configurations and plugins for days/weeks and constantly having a broken environment!
Configuration hell is the worst path to get into neovim! Start with the starter kit but avoid going into installing 10s of plugins, custom key-mappings and themes until you have learned the fundamental of motions, navigations and editing.
The ecosystem of vim package managers and plugins is even more diverse and dynamic and hence confusing than the JS frontend one. The more things get built-in (like LSP in neovim) the better. This is the reason there are distributions of vim (Astro, NVChad, Lunar, Lazy) which are convenient for quickly starting but are extra layers or complexity and a source of issues and time wasted.
> The more things get built-in (like LSP in neovim) the better.
Since someone inevitably mentions Helix on the *vim threads (and vice versa), I'll be that person today.
This is one of the things I think Helix gets right. It has the LSP, fuzzy finder, and a few other modern tablestakes features built-in, which makes it a joy to use. I spent a decade+ using (Neo)vim, and went from a few hundred lines of homegrown vimrc to maybe 6 or 7 lines of Helix config, for a few bits of muscle memory I couldn't shake.
Not the OP, but surprisingly it didn’t take long. I just worked through the helix-tutor and was good to go in a few hours. Helix isn’t simply an alternative set of keybindings—it’s a different way of thinking about selections and actions. Once that thinking becomes intuitive, Helix’s keybindings just come naturally.
Same as sxg, it was surprisingly easy. Maybe a day or two of fumbling around before I got into the usual flow with it.
I still use vi mode for bash, and occasionally use Vim on systems without Helix. I definitely stumble a bit now, but it seems possible to retain muscle memory for both without much effort.
I mainly use Evil mode on Emacs, but have switched to use Helix for when I need a terminal editor.
It feels like the majority of Helix keybindings are the same as vim. Similar to how with vi-emulators, you'll bump into things you use that the emulator doesn't have; with Helix, you'll bump into keybindings you expect, which are different in Helix.
https://gist.github.com/rgoulter/af83932a45c79f9f3fb673d8813...
The impression I get is that Helix's keybindings are well thought out. e.g. u/U for undo/redo vs vim's u/C-r. e.g. rather than Vim's H/M/L, Helix uses "go top"/"go centre"/"go bottom" (gt/gc/gb); and the bindings which jump the cursor around all use this `g` prefix.
Switching back and forth between Vim and Helix, there'll still be false-friends from time to time.
Just checked the script and indeed, compared to the youtube video of 10 months ago, the kickstart script now uses 'lazy' instead of 'packer' as a package manager.
LazyVim the distro is different from lazy.nvim the package manager. Both are written by folke and are excellent. Not sure why parent comment says these are extra layers of complexity. LazyVim is written in a way you can selectively disable or enable the plug-ins it uses. I can't imagine why 80% of these plug-ins would ever make their way into neovim core.
I say they are complexity because first there are a lot of ways to configure nvim by using any of the distros and starting kits and then they are slightly incompatible and use different versions of package managers, fuzzy finders, autocompleters etc. I agree most need not be in core, but it would be better to have fewer plugins doing more or less the same thing and having to find the ones that are less buggy and are being maintained. To be fair this was an issue with vim too, it's not nvim specific.
The one component of my IDE that I couldn’t translate is my EA inspections plug-in. There’s no compatible equivalent and it’s an integral part of my workflow.
With so much effort spent on improving the editor ecosystem to the point of creating a new fork, why is the ugly duckling of old defaults so sticky and prevents neovim from becoming effective?
Fwiw they are changing old defaults. What defaults do you think prevents you from being effective, except some large plugins that maybe should be included (like LSP)?
Interesting that illustrating the virtues of the "amazing" help ~9:45 is a typical relatively poor doc: besides the fact that it wastes too much horizontal space due to all the hardcoded line breaks, it misses a simple thing that would make it way faster to understand: a simple picture with relative numbers and a few callouts
I recently switched away from Neovim. I had a really deep and ergonomic set of customizations - and I liked where it was. The problem is that it kept breaking with each update of the editor/plugins and I grew too fatigued to keep figuring out how to fix it.
Helix isn't nearly as nice as my purpose-built Neovim setup, but it keeps working.
59 comments
[ 3.4 ms ] story [ 114 ms ] threadI know that sounds complex but if you're coding (which I assume many neovim users are) should be fairly straightforward
I do get that the Vim editing model is hard, but that professional developers refuse using a tool because you have to change some defaults and customize it a little is too much.
It's really not that hard or time consuming to setup, for more gains than many of the courses or experiences people have put themselves through.
And it's not like it's a "vscode vs Vim" thing, I see the same argument inside the Vim community too where people refuse plugins because it's too much work, or even switch to Vim-like editors that don't have a plugin system as if it was a positive thing.
What gives? I'm sure it's not as easy as everyone just being lazy.
Maybe it's the perseption that it's hard and time consuming that's the problem?
Second, it's not fast and easy even with LazyVim, let's start with the basics like keymap:
map({ "n", "x" }, "j", "v:count == 0 ? 'gj' : 'j'", { expr = true, silent = true })
map("n", "<C-h>", "<C-w>h", { desc = "Go to left window", remap = true })
To understand this (and to adjust to your liking) you kind of have to learn the language you're not going to use ('gj' or <C-w>h) instead of using something easily readable like ["go","window","left"], or instead of actually pressing C-w to insert <C-w> like many (mostly GUI) apps allow
Then the time consuming part: it doesn't make it easy to resolve conlficts which inevitably arise when doing many rebinds. Also, it'd be very time consuming to learn and reference that unused binding language
Then the help is rather verbose and not intuitive (see my parent comment) (don't remember if help uses default keybinds or actual ones
Then it relies on a very barebones and not very popular language (though miles better than vimscript)
Then there are a gazillion of other things which make the perception reflect the reality pretty well
Enthusiasts are familiar with a lot more, know the domain, and so are able to navigate the intricacies. -- There's an xkcd comic which points out that you're probably under-estimating what it takes to be familiar with this stuff. https://www.explainxkcd.com/wiki/index.php/2501:_Average_Fam... -- And while it's nice to be enthusiastic about stuff, not everyone's going to have full enthusiasm for everything they do.
In terms of accessibility:
Having "bad defaults out of the box" just doesn't make sense compared to "having good defaults out of the box". If it's very unusual, or unintuitive to use, that's just added friction to get someone to learn. (And if fewer people adopting a tool leads to a smaller community).
There's plenty of stuff which isn't so hard if you know where to look.. whereas, without knowing where to look, it's confusing to navigate.
There's a communal cost to having fragmented/bespoke setups; if everyone's using pretty much the same thing, then anyone can help anyone out. -- Someone familiar with the intricacies will be able to understand the differences, but a novice might not know which bespoke thing would be best to copy.
The xkcd hits home hard.
This is exactly my problem any time I try and get in to Vim/Emacs/NeoVim, even when trying some pre built config like Doom Emacs, LunarVim etc. Everybody has some bespoke setup so following along from a tutorial is a fucking nightmare because inevitably something will be out of date, or they'll be using a different package for say the file browser that makes it incompatible with the one you're using that you picked up from the previous tutorial. Or they'll be using a different package manager entirely, of which a new one seems to come out every year. Or you're fucking around trying to get LSP to work again because something has broke it. Or you'll try installing some kind of manager to let you switch between the different premade versions such as Doom Emacs and SpaceMacs and that won't work properly because Doom has been updated since it was written etc. It's just a never ending torrent of pain. It's the editor equivalent of the JavaScript ecosystem where there's some new shiny half baked bullshit every week. It's so much easier to just use VSCode or Jetbrains and have a consistent and reliable experience every time.
I went deep and set up a neovim config, forcing myself to use neovim full time. However my new role requires me to use Intellij and I didn't want to spend hours upon hours figuring out how to replicate the java support in Neovim (and no, it isn't just installing the LSP, my work has some pretty specific intellij setup).
At this point I'm just using Intellij and VSCode with their respective vim plugins and I'm getting about 80% of the utility that I did with pure neovim. The one thing I really love about neovim is that it really forces you to keep your hands on the keyboard and you learn the keybinds very well because otherwise you just can't do the thing you wanted to! I find myself using the mouse a lot in VSCode and Intellij because they give you really handy buttons to click on.
I could probably go pure keyboard if I just sat down and learned all the various keybinds, but who has time for that?
Particularly, I’ve found the undo functionality to be far better with the neovim one, it never screws up. Holding alt and moving a line up and down can sometimes accidentally move your cursor one line higher or lower though.
VSCode extensions can change crazy stuff such as [1], and are also more numerous. I don't see much of an advantage to terminal-vim apart from performance and perhaps an inherent joy of building your own tools.
[1] https://marketplace.visualstudio.com/items?itemName=hoovercj...
https://www.youtube.com/watch?v=QMVIJhC9Veg
The tl;dw is that the term 'PDE' means the tool requires some work in order to personalise, but because neovim exposes a robust API that work is fun and rewarding. Additionally, he makes the point that because you configure it in the same language as you script it with (lua), you have much greater control over how all the pieces fit together.
My only gripe is his requirement that the majority of users must make use of the scripting system in order for the program to be considered a PDE. If only 1% of all IntelliJ users ever use the Program Structure Interface or the powerful Live-Templating system, that's still a respectable number in total. And it also doesn't mean IntelliJ is less personalizable.
Maybe a better term would be a DIY-DE.
This is the kind of thing I would expect to see in emacs.
That said, I can't imagine ever wanting to have a website render in my own editor, that's the kind of thing I'd like to use my target browser for.
Also, most markdown ssg's have hot-reloading.
[0]: https://m.youtube.com/watch?v=w7i4amO_zaE
Building a mental and muscle memory is tough but it requires grinding. You have to put in the time! It took me months!
My biggest mistake was starting and playing around with configurations and plugins for days/weeks and constantly having a broken environment!
Configuration hell is the worst path to get into neovim! Start with the starter kit but avoid going into installing 10s of plugins, custom key-mappings and themes until you have learned the fundamental of motions, navigations and editing.
Starter kit: https://github.com/nvim-lua/kickstart.nvim
Since someone inevitably mentions Helix on the *vim threads (and vice versa), I'll be that person today.
This is one of the things I think Helix gets right. It has the LSP, fuzzy finder, and a few other modern tablestakes features built-in, which makes it a joy to use. I spent a decade+ using (Neo)vim, and went from a few hundred lines of homegrown vimrc to maybe 6 or 7 lines of Helix config, for a few bits of muscle memory I couldn't shake.
I still use vi mode for bash, and occasionally use Vim on systems without Helix. I definitely stumble a bit now, but it seems possible to retain muscle memory for both without much effort.
It feels like the majority of Helix keybindings are the same as vim. Similar to how with vi-emulators, you'll bump into things you use that the emulator doesn't have; with Helix, you'll bump into keybindings you expect, which are different in Helix. https://gist.github.com/rgoulter/af83932a45c79f9f3fb673d8813...
The impression I get is that Helix's keybindings are well thought out. e.g. u/U for undo/redo vs vim's u/C-r. e.g. rather than Vim's H/M/L, Helix uses "go top"/"go centre"/"go bottom" (gt/gc/gb); and the bindings which jump the cursor around all use this `g` prefix.
Switching back and forth between Vim and Helix, there'll still be false-friends from time to time.
1. by using a serial image protocol
2. by drawing the picture in text
https://handwiki.org/wiki/Sixel
https://www.arewesixelyet.com/
Helix isn't nearly as nice as my purpose-built Neovim setup, but it keeps working.