Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with.
In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.
Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason.
I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.
Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668)
> Couldn't they not convince Bram Moolenaar of proposed changes
I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason.
That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript.
But that's how I remember it being started at least, but I could remember it wrong.
Of course I am stretching things a little, I know.
I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.
To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.
Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors.
So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.
Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.
I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.
Then neovim wouldn't have got off the ground.
Once they started building, they wanted to "cut the cruft" and just went from there
Not to mention that there are currently a lot of great plugins written in lua, and I anticipate there will be great plugins written using vim9.
Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster.
I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.
Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible".
You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter.
> I wish he’d have embraced Lua like Neovim
Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.
Vim9 script and legacy Vim script can be mixed. There is no requirement to
rewrite old scripts, they keep working as before. You may want to use a few
:def functions for code that needs to be fast.
My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
[1] https://insights.stackoverflow.com/survey/2021#section-most-...
Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (like embedded, firmware, etc) would skew even more heavily in the direction of vim + no SO usage.
Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups.
Out of the different plugins, which would you never operate without?
set tabstop=4
set expandtab
set shiftwidth=4 " or 2 or whatever
set shiftround
syntax on
Just for some fun archeology, I google searched on the 3rd line, 'set shiftwidth=4 " or 2 or whatever' because I very dimly recall copying most of my standard set (minus the syntax on bit) from someone else a long long time ago. This was the only hit I found:
https://www.perlmonks.org/index.qs1968.pl/perlmonks.org?disp...
set expandtab shiftwidth=4 softtabstop=4 tabstop=4
syntax on
set number
inoremap jk <Esc> set number
setlocal cm=blowfish2
set noswapfile
set nobackup
set nowritebackup
set viminfo=
set tabstop=4
set softtabstop=0 noexpandtab
set shiftwidth=4
set noundofile
set backspace=indent,eol,start
set autoindent
set smartindent
set cindent
autocmd BufRead,BufNewFile *.vue setfiletype html
colorscheme morning
map Q <Nop>
map q <Nop>
noremap x "_x
let &t_ut=''
if has("gui_running")
:set guifont=Cascadia_Mono:h16:cANSI:qDRAFT
endif " My vimrc from 1994 to about 2000
set et
set ts=4
" Added this circa 2000
syntax on
" Added this ~2013
let g:solarized_termcolors=256
set background=light
colorscheme solarizednoremap ; l
noremap l k
noremap k j
noremap j h
- neoterm, for opening a REPL in a split buffer and quickly sending chunks of lines to the REPL (https://github.com/kassio/neoterm)
- fzf for faster buffer and file navigation (https://github.com/junegunn/fzf.vim)
- vim fugitive for good git integration (https://github.com/tpope/vim-fugitive)
- some other tpope plugins (surround, unimpared, commentary, vinegar)
The most important ones lately seem to be the LSP integrations (basically IDE features like autocompletion, go-to-definition etc) and auto-completion managers. But honestly it's been breaking all the time over the last year or so that I code more often in VSCode and maybe it's about time I stop trying to make an ever-improving IDE out of Neovim :(
Neovim project's direction seems to be aligned with making it easier to have IDE-like experience with LSP integration but it's been painful in Neovim. In Vim, it's typically even worse and even harder to set it up.
Overall, I've been using Vim for about 8 years and went from a really simple set-up of "this is just a text editor" down the IDE rabbit hole. I also went for Vim -> Neovim -> Vim -> Neovim and eventual split of the two configs in the end and. I'm thinking about making it much simpler again :D
I have a quite extensive setup (https://github.com/Julian/dotfiles/tree/main/.config/nvim) which I built up over 10+ years, indeed sometimes including sitting there for an hour or two and just investigating plugins or writing some function to make editing easier. I enjoy it, and it means I can do lots of things in my setup that involved time investment.
Others obviously just want to get on with their work.
To me though part of the reason I use vim/neovim is because anytime something annoys me about editing I can automate it, or find a plugin which has done so already.
Every once in awhile I think I might do a fancier setup but then I lose interest. Ditto for checking out neovim. I'm sure I'd get some gains, but I guess I've sort of settled into a decent sweet spot that I haven't left for almost a decade, haha (been using vim for ~25 years total).
Since this editor (and Emacs) are SO extensible, it's hard to find two long-time users with similar configs.
Previously to managing my dotfiles, my .vimrc was usually 4-5 lines, written by hand on each machine I sat at. This was my first 20+ years of vi/vim.
Once I started managing dotfiles across systems (~3 years ago), my .vimrc has grown to be ~700 lines. My .bashrc has also grown to almost as much for reference.
Like most, the work in customizing .vimrc is in configuring plugins and making sure they don't conflict with each other, but also, I've taken care so that I can use the same configs across Linux and Windows, allowing me to use the same tools, plugins and configurations regardless of the underlying OS. Neovim is my tool of choice on both OSes but my configs fallback well to vim or other vi implementations rather gracefully (via bash/pwsh alias trickery) for when needed.
Regarding plugins that I would never operate without (of the many installed): - nerdtree (and friends like nerdtree-git-plugin, vim-nerdtree-syntax, vim-devicons) for decent file nav integration - vim-fugitive (Git integrated into vim, makes interactive commit creation and navigation easy from within vim) - Coc for language server support that works on both sides of the fork and vscode like plugins.
Also, not a plugin, but worth configuring in your environment: neovim-remote. I use this to make "vi <file>" open the file in a new tab, rather than start a nested editor, from within a terminal window within neovim (again with more shell alias trickery dependent upon $NVIM_LISTEN_ADDRESS being set or not). Using it for $EDITOR and $VISUAL when NVIM_LISTEN_ADDRESS is set is also really useful when invoked indirectly by tools being run in a windowed terminal e.g. "git commit" or "kubectl edit".
If you aren't tracking dotfiles, I really suggest you start. It's really cool to be able to sit at a new system, sync some files and get your editor / development environment installed/booted with all the bells and whistles you like installed ready to go. You will find that there is no end to this rabbit hole in the end. I think that's a good thing :)
Vim only has that reputation of needing a lot of config because too many newbies want to skip the learning phase and just jump in between two JIRA tickets. Of course you will need a lot of plugins and pre-baked stuff and hand-holding in that case!
The more sensible path is to learn Vim properly, and configure it as you go. It means that there's never a "take the week-end to configure Vim for React" moment: it's one line here, two lines there and it never really stops because you work with new languages and libs, etc.
As far as plugins. I can use Vim just fine without plugins or without my config but half of the plugins I use are written by me and tailored around my own needs so I guess those are the ones I need the most for my daily use.
One of the issues I found was that every plugin seemed to reference other plugins and you need to figure out how to make them play nicely together yourself. Most of the best info is just buried in GitHub issues and neovim was such a moving target that everything needed more digging into to get working correctly.
For me now essentials include; Telescope, Trouble, Cmp and a good LSP setup.
$ du -s -h .vim
22M .vim
Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).
The plugin that I find myself using all the time is vim-surround with a couple of minor language-specific tweaks.
The editing plugins I use most heavily are probably vim-surround and vim-commentary. My development would definitely slow down without them.
I would say that the plugins I could not do without are:
- vim-polyglot
- syntastic
- nerdtree
- coc.vim
Go Vim!
Other changes: https://vimhelp.org/version9.txt.html
https://github.com/nvim-treesitter/nvim-treesitter/issues/80...
So it should be possible in theory to use treesitter data to calculate indents, though it seems difficult.
I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate.
And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was.
As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me.
(home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)
I never really enjoyed having to configure vim. What I like about vim is the idea of modal editing which and the fact it runs and interacts in/with the shell. Still waiting a bit more before making the jump.
I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.
However, I use Emacs and VS Code for more involved editing, and mostly use vim as a light remote editor via SSH, so my priorities may be very different.
- https://qa.debian.org/popcon.php?package=vim
- https://qa.debian.org/popcon.php?package=neovim
- https://qa.debian.org/popcon.php?package=nano
(nano for the control group)
So lots of neovim growth, but still small in absolute numbers. Then again, vim-tiny is installed by default. Normal vim is a better indicator. And it won't grow as much, because Debian's userbase grows slowly.
Personally I'm happy with the default Vim config (I'll enable features if I need them, such as line numbers) and prefer the minimalism.
I tried neovim but there were more bells and whistles by default, and I didn't want to waste time configuring (and I work on a bunch of machines when wearing my sysadnin hat). For plugins, I only use a debugger.
94000 installs for vim
4000 installs for neovim
I see the neovim community holding up lua as a holy grail, rewriting entire vimrc configs just for the sake of it (even though a vimscript vimrc is much easier to read than a lua one) and rewriting rock solid existing vim plugins in lua, resulting often in a less stable and less feature complete plugin. But hey, it's now written in lua so it MUST be better!
https://news.ycombinator.com/item?id=31908731
A few highlights:
* "If it ain't broke, don't fix it"
* People don't like Lua (or just simply prefer VimScript)
* Divergence over time means that they are not still compatible.
Really surprised to see /Debian/ of all things pick Neovim, especially years ago when it was even newer, as a default over Vim and would love to see the discussion around it. It would have been ~v0.2 for Stretch and ~0.3 for Buster, and only a year old during Jesse.
So...they make a new language to fix that? Couldn't they just use an existing language?
I still use vim from time to time on terminals, but I don't miss it at all as an IDE.
For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and requires way more fidgeting, setup and hacking to just barely be useful.
When I made the switch, Bram was still vocal about how he regarded the sort of language support plugins I wanted as undesirable or irrelevant, and made no effort to accommodate things like LSP. This has changed, but at this point, it's too late. VS Code supports all the languages I need through a set of plugins it wouldn't even be possible to implement for vim, with no fidgeting required. Although I still love vim's text editing capabilities, they're not nearly enough to tip the scales.
I still use vim for quick text file stuff, and even write commit messages in vim in VS Code's terminal. For actual development though, it'll never be as powerful and low maintenance as VS Code.
I tried neovim-based vscode integration and didn’t find it comfortable enough.
^ I don’t really care of one or another way of formatting, but it messes with my code way too much, cause I’m using hyperscript not jsx. The way these linters format highly hierarchical calls is just stupidly bad.
Vim is sort-of the defacto reality in my life now, but if two or three things around tab expansion and tab-to-space got fixed, I'd stick to nvi compiled and installed from pkg/ports/homebrew over anything else.
A vimrc could revert this to standard behaviour, but that means having to have a vimrc file.
I was disappointed in those decisions.
But most Vim addons seem to be written in Vimscript, and porting them to another language (which?) is a lot of work for little practical gain (for many/most addons).
I've been using LunarVim/Neovim lately, and it is PHENOMENAL. Highly recommended!