…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
Well, sure, if the appeal of vim for you is that it “just works” on every platform you use, then there’s no advantage to adopting neovim. That’s no reason to complain that neovim isn’t meeting your needs, though.
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
Well, sure, if the appeal of vim for you is that it “just works” on every platform you use, then there’s no advantage to adopting neovim. That’s no reason to complain that neovim isn’t meeting your needs, though.