Am I the only one to still use regular vim? I tried to switch to Neovim a few years ago, but there were a few things I didn’t like, so I switched back. Vim has improved tremendously, so I no longer feel a need to switch. With LSP and Copilot, I feel that I am close to the optimal dev environment these days…
…I admit it’s annoying that you need a new config file, but on the other hand, it’s nice that it follows the xdg spec. Also there’s really only one new file you need (init.vim) and it can just source your vimrc.
It broke vim compatibility with this one change. That is super easy to support for painless migration. A real no brainer imo. The docs don’t explain your easy fix either. The key to making change faster: make it easier for people
Excellent, TIL. It should be bash scripts though. Setting strange write modes and obfusticating paths, combined with a set and a let (now having to go learn the difference) isn’t something I would recommend to anyone.
Add alias vim=nvim --vimrc-compatibility to your ~/.bashrc would be my prefered migration path
I’m sympathetic to the desire for an “install and forget” drop-in Vim replacement, but…don’t you think that this runs contrary to the purpose of Vim/NeoVim as a flexible, customizable editor? If you’re an advanced enough user to have a nontrivial vimrc, then it’s entirely possible that you’d also want different configurations for vim vs nvim, and that you’d want to be able to switch between them easily if you discover something doesn’t work in nvim (especially since nvim is not yet at version 1.0). It’s also probable that a lot of Vim users wish that more classic Unix/POSIX tools followed XDG, rather than requiring rc files in your home directory. As for Bash, not everyone uses it, there’s no reliable way to automatically insert content into a bashrc file without potentially screwing things up, and Windows doesn’t even have a reliable way to run a Bash script (assuming some version of Bash is even installed).
I do think it would be reasonable for the neovim installer (on all systems) to have an option to create an init.vim file that reads your vimrc, and possibly even to create a shell alias as you describe. But these should definitely be opt-in, not opt-out.
For me vim is one of those things that just works. It’s ever present, reliable, and dependable. The simplicity of it mirrors the unix way and my usage of it is so closely wrapped in screen,
/tmux, bash, gnu-coreutils, and a few terminals over the years that any change is going to have me asking ‘why?’ essentially. So a command line flag allows familiarity of existing tooling to really sing, and I suspect offers far more compatibility than the suggested fix too given the length of the windows addendum to the guide
And totally agreed about out in, I use Arch btw. And I’m not in a hurry to switch to nvim either, I tried and switched back pretty quickly. Pathogen is still an amazing plugin system, leveraging my git and bash knowledge to boot
I mean, I’d just bind vim to nvim. If you still want vim accessible, bind it to something else. I don’t really see any downsides to Neovim: it’s decently backwards compatible, enough to use most old plugins, with the advantages of Lua config and a much wider repository of plugins.
I did bind it, but it still had a few annoyances (that I no longer remember what they are because it was a few years ago). I couldn’t really find a reason for me to use it other than people recommending it. I guess my use case is a bit different from theirs or something. Either way, I’m used to regular Vim now, so I don’t care to switch
That’s fair. I started with what everyone was using at the time, which just so happened to be Neovim. I’m also too lazy to switch/try anything else.
Plus, I’m not sure if Neovim simply extends Vim functionality. I know it’s a fork, but the codebase has changed so much I’m pretty sure many newer features of Vim need to be manually added to Neovim. Inlay hints in the middle of lines is already implemented in Vim: as for Neovim, it’s not here yet (well, it’s coming in 0.10, but I don’t use nightly so I don’t have it)
The biggest difference that I know of is Neovim uses Lua instead of Vimscript for plugins. I’m sure there’s some other stuff tacked on but idk what haha
With Bram Moolenaar death, I sincerely think that vim will no longer be able to play catch-up with nvim. Bram Moolenaar did an amazing job with nvim, but with its death I think that vim is going to be an editor of the past, just like vi is an editor of the past. And nvim is its successor since its where the developers have moved.
Vim9script is fine, I write enough small scripts in it that it hasn’t annoyed me. Vim’s plugins, and NerdTree in particular, make it a perfectly good editor for this millennium as well as the last.
I did similar. Tried out nvim, thinking here’s the new vim with everything I like from vim plus new benefits… didn’t have a great experience. Switched back to vim; been happy since.
Don’t remember what it was that put me off nvim, but hey, I like vim.
Now I’m excited for Lapce; but it has some way to come before I can use it happily without learning how to tweak it myself.
And still sometimes I wonder about going back to Emacs for some things, but with eVil mode!
Am I the only one to still use regular vim? I tried to switch to Neovim a few years ago, but there were a few things I didn’t like, so I switched back. Vim has improved tremendously, so I no longer feel a need to switch. With LSP and Copilot, I feel that I am close to the optimal dev environment these days…
I use so few features I could be using a 30 year old vi and not know it.
Curious what you don’t like about it. I only just swapped over and haven’t noticed much of a change yet
Nope. Still on regular myself. Pry my .vimrc and .vim/plugins folder from my cold dead fingers
Neovim is a fork; it’s compatible with those.
It fucks about with locations too much for my liking
…I admit it’s annoying that you need a new config file, but on the other hand, it’s nice that it follows the xdg spec. Also there’s really only one new file you need (init.vim) and it can just source your vimrc.
It broke vim compatibility with this one change. That is super easy to support for painless migration. A real no brainer imo. The docs don’t explain your easy fix either. The key to making change faster: make it easier for people
What do you mean, the docs don’t explain the fix? One of the most prominent topics in the documentation is how to migrate from vim: https://neovim.io/doc/user/nvim.html#nvim-from-vim
Excellent, TIL. It should be bash scripts though. Setting strange write modes and obfusticating paths, combined with a set and a let (now having to go learn the difference) isn’t something I would recommend to anyone.
Add
alias vim=nvim --vimrc-compatibilityto your ~/.bashrc would be my prefered migration pathI’m sympathetic to the desire for an “install and forget” drop-in Vim replacement, but…don’t you think that this runs contrary to the purpose of Vim/NeoVim as a flexible, customizable editor? If you’re an advanced enough user to have a nontrivial vimrc, then it’s entirely possible that you’d also want different configurations for vim vs nvim, and that you’d want to be able to switch between them easily if you discover something doesn’t work in nvim (especially since nvim is not yet at version 1.0). It’s also probable that a lot of Vim users wish that more classic Unix/POSIX tools followed XDG, rather than requiring rc files in your home directory. As for Bash, not everyone uses it, there’s no reliable way to automatically insert content into a bashrc file without potentially screwing things up, and Windows doesn’t even have a reliable way to run a Bash script (assuming some version of Bash is even installed).
I do think it would be reasonable for the neovim installer (on all systems) to have an option to create an init.vim file that reads your vimrc, and possibly even to create a shell alias as you describe. But these should definitely be opt-in, not opt-out.
For me vim is one of those things that just works. It’s ever present, reliable, and dependable. The simplicity of it mirrors the unix way and my usage of it is so closely wrapped in screen, /tmux, bash, gnu-coreutils, and a few terminals over the years that any change is going to have me asking ‘why?’ essentially. So a command line flag allows familiarity of existing tooling to really sing, and I suspect offers far more compatibility than the suggested fix too given the length of the windows addendum to the guide
And totally agreed about out in, I use Arch btw. And I’m not in a hurry to switch to nvim either, I tried and switched back pretty quickly. Pathogen is still an amazing plugin system, leveraging my git and bash knowledge to boot
I use regular vim. I hated typing the extra letter for neovim and didn’t find myself using any of its extra features anyway.
I mean, I’d just bind vim to nvim. If you still want vim accessible, bind it to something else. I don’t really see any downsides to Neovim: it’s decently backwards compatible, enough to use most old plugins, with the advantages of Lua config and a much wider repository of plugins.
I did bind it, but it still had a few annoyances (that I no longer remember what they are because it was a few years ago). I couldn’t really find a reason for me to use it other than people recommending it. I guess my use case is a bit different from theirs or something. Either way, I’m used to regular Vim now, so I don’t care to switch
That’s fair. I started with what everyone was using at the time, which just so happened to be Neovim. I’m also too lazy to switch/try anything else.
Plus, I’m not sure if Neovim simply extends Vim functionality. I know it’s a fork, but the codebase has changed so much I’m pretty sure many newer features of Vim need to be manually added to Neovim. Inlay hints in the middle of lines is already implemented in Vim: as for Neovim, it’s not here yet (well, it’s coming in 0.10, but I don’t use nightly so I don’t have it)
The biggest difference that I know of is Neovim uses Lua instead of Vimscript for plugins. I’m sure there’s some other stuff tacked on but idk what haha
With Bram Moolenaar death, I sincerely think that vim will no longer be able to play catch-up with nvim. Bram Moolenaar did an amazing job with nvim, but with its death I think that vim is going to be an editor of the past, just like vi is an editor of the past. And nvim is its successor since its where the developers have moved.
yeah, you’re literally commenting on a post about a new release six months after BM death
1.6 million js frameworks have both been created and forgotten during this period.
Make that 1.6 million and 1.
uh?
Oh dear.
It’s a JavaScript joke.
deleted by creator
ah, I see. Do you have an idea what we are talking about here? :)
Maximum autism
ah, all makes sense now ¯\_(ツ)_/¯
I’m staying with Vim, mainly because I hate Lua.
Vim9script is fine, I write enough small scripts in it that it hasn’t annoyed me. Vim’s plugins, and NerdTree in particular, make it a perfectly good editor for this millennium as well as the last.
I did similar. Tried out nvim, thinking here’s the new vim with everything I like from vim plus new benefits… didn’t have a great experience. Switched back to vim; been happy since.
Don’t remember what it was that put me off nvim, but hey, I like vim.
Now I’m excited for Lapce; but it has some way to come before I can use it happily without learning how to tweak it myself.
And still sometimes I wonder about going back to Emacs for some things, but with eVil mode!
I use it daily, with ultisnips, to write reports at work!