Say what you want about Neovim, but it sure motivated Bram to make Vim better again. Almost everything listed here looks like a direct reaction to features Neovim has added. Same for older releases (async, terminal, etc.).
Just out of curiosity (and this goes into the subject of open source project dynamics of which I am really just a lay observer, and as someone who hasn't followed the history of either projects closely) - how is vim vs neovim organized as open source projects? Do both have a healthy ecosystem of contributor/maintaners? Are either in danger of running into "single person syndrome" or "hit-by-a-bus" syndrome?
Neovim was started pretty explicitly to be a community project. There's a main maintainer but there's no BDFL. Vim has Bram as BDFL.
I'd say that for (Neo)Vim, which is a mature project with a clear design, the BDFL approach is ok but there are risks, illustrated by the half decade where Vim stagnated. Neovim has a less risky approach to project management, I'd say.
Of course, we need to revisit this topic in a decade or so :-)
ps: I honestly wonder if it's a competition feeling or just a side-induced motivation. Sometimes I look at people online and it revives the desire to do things they do that I couldn't before.
I switched to NeoVim a few years ago and I'm not entirely sure whether Vim has caught up in features, diverged, or what ratio of the two. That said, I'm not switching back. The only editor I'm really interested in is VSCode. Not that I use it much, but I am very impressed.
If you go back to early stories of Bram, the BDFL, when others tried to add Neovim features to vim. He wasn't onboard. Not to discount all the amazing contributions he has done and his importance. But I just think it is karma.
If you read Thiagos's message about job/channel features you will notice a couple of points he made.
1. NeoVim made the channel/job feature first, so vim should follow it.
2. Vim's design is broken.
3. Bram should write new features for NeoVim first, why no PR's Bram?? Why no PRs to neovim?
Thiago is clearly an asshole. Sorry but I think Bram was reasonable and polite with his responses. His opinion about NeoVim's version is that it was too complicated, and he was right.
The problem is NeoVim started off on the wrong foot trying to throw away decades of work and then expecting Bram to implement new vim features? Seriously Thiago?
I still use both but lately Neovim just works better although I think it uses more memory. It could be the appimage though. Most of the extensions that I use in Neovim are written in VimL (Pathogen and Lightline and the Monokai Tasty color scheme). In some terminals (Xfce term) nvim messes up vim paste until you reset the term. It's very annoying.
The really big news is that vim is now a game engine too;-)
> To show what is possible with popup windows (and because I sometimes get bored fixing bugs), I created a silly game. This uses popup windows that move across the display, text properties to highlight the animals and even sound to make it more fun!
I've never gotten gVim to look anything but horrible. (Haven't tried in a few years, so just installed this one and the window and font are so small they would require a hefty magnifying glass to use.)
AFAICT, the sanest version of "real" vim that seems turnkey is the version of vim that runs in git bash in the cygwin shell that installs with git extension for windows.
Other than that, the VS and VSCode vi emulators do most of what I want and then I'm not tempted to to go down the dark hole of vim extensions.
I'm using plain vim occasionally, but never tried to do any coding in it, just because I'm not sure how to configure it for that. Which plugins for Python coding are universally agreed on as "must haves" Preferably just one, or two at most.
> Which plugins for Python coding are universally agreed on as "must haves" Preferably just one, or two at most.
I wrote Python in Vim for about 15 years before finding python-mode[0] about 4 years ago and I now find it absolutely indispensable.
Just about the only thing that it doesn't do natively is Black[1] (think gofmt for Python) which I started using a few months ago. It's not too hard to run it occasionally on my codebase, but I hope it's added in soon.
python-mode did remove its folding capabilties some time back, but it was easy to use another plugin for that: vim-coiled-snake[2].
Apart from these two plugins, and vim-fugitive[3] for git (another one that is a must-have), I don't use anything else except for the occasional syntax coloring plugin.
I've always used the NetRW plugin for file management. NERDTree was too sluggish for me (but that was 6 years ago...)
NetRW does all I need to: tree view, open file (same buffer, same side-buffer, new buffer, new tab), create file, delete file. And it comes with vim's distribution.
Anything else I need I use a real file manager, like Midnight Commander (usually inside a vim's tab) of vifm (a very vi-like file manager).
I used vim for a development IDE and customized extensively. These days, I've had to relearn stock vim, since I tend to log onto many corporate servers that aren't guaranteed to have my environment/plugins/settings. Also, the state of C++ syntax/symbol parsing wasn't where I needed it to be. Maybe it's gotten better?
I've found Nerdtree to be most indispensable. Other good ones are pathogen, ctrlp, a.vim, and vim-gitgutter
This refers to the Language Server Protocol [1] which is intended to decouple the IDE features from your editor so you can use it with any editor, such as Vim.
Vim's included Python support already does language-specific stuff like syntax highlighting and indenting. I think people use Jedi for autocomplete; I've never used it.
I'm one of the "computing for the apocalypse" people who try and configure things as little as possible, but I'm really attached to linting in Vim, and I use ALE [1] for this. AIUI it's the standard for asynchronous linting; Syntastic is the synchronous version, but the lag is juuuust a little too much for me.
netrw (Vim's included file browser plugin) has a lot of bugs on macOS, so I use NERDtree there, but have been thinking about looking around at nnn, defx, vim-netranger, etc.
Other than that, Vim has a lot of powerful configuration. It's worth looking around and fixing any immediate pain points you have; odds are there's an option that does what you want. Three cheers for mature software!
I use Vim to code, but it took me a lot of time to find to configure it. My primary need when coding is quick jump to symbol definition, and after many trial and error attempts, settled on the plugins `vimprj` and `indexer` in combination with Universal Ctags. Have been using this setup for years and it's proven to be stable and giving me the result I need.
But I hate Vim.
It's so fragile. Configuring it is a nightmare. One buggy plugin could cause weird behaviour in the editor, and I'd had a hard time figuring out why.
In a recent incident of this kind, I noticed that the scrolling of syntax highlihted code became horribly slow, and the cause turned out to be the new regex engine of Vim 8.
So I've compiled Vim 7.4 from scratch, and intend on using that version till the end of time.
By the way - my plugins are manually installed and I never upgrade them. Ever.
I tried to switch to other editors several times, but couldn't make the transitions for several reasons: ) My editing workflow now is tightly tied to Vim, for example the normal/insert mode paradigm. ) The capability to navigate using hjkl is helping with my RSI condition, because I find that it helps to offload some of the workload on the wrist of the right hand. When editing in Vim, as compared to other traditional editors, my hands get less tired. *) Other editors have their own quircks, and I don't want to spend yet another number of years to adjust.
I've decided that the next time I switch to an editor, it's going to be to one written by myself.
You don't necessarily need any plugins. Vanilla Vim with the occasional ctrl+N is often enough. If you need a more powerful editor, perhaps it's better to just use something like VS Code.
You don't need any for python, really. You can run pdb in your :term split, which is nice. Other than that you only really get the vim advantage over IDE if you practice.
Check out VimAwesome (https://vimawesome.com) for finding plugins. They provide instructions for installing each plugin via Vundle, NeoBundle, VimPlug, and Pathogen.
I don't think the problem is finding vim plugins. It's more of choosing the best one. I don't want to spend a ton of time trying dozens of them.
What would be a single, simple thing I should do to improve Python coding experience when I login to some remote server? E.g. open .vimrc, put a few lines there, download/install plugin X.
Would you modify vimrc at all on a remote server if you had to do some Python coding there? I mean maybe a few hours of coding, but you won't be coding again on that server, so you don't want to spend too much time configuring it.
Haven't been in that situation, but looking through my vimrc, the only things that I think I'd consider updating are turning off line wrap and changing the tab settings.
Basically this block:
set ts=3
set expandtab
set sw=3
set nosmartindent
set nowrap
I don't know what all of those mean, but I like how my vim works. Usually if I'm editing files on a server its just editing configuration files, and I just use whatever the stock vim settings are.
Wow. For a "minor" release, this is really exciting. Finally, vim gets text properties. This could be a real game changer for plugin writers. Popup windows could also be interesting.
At this point, vim is hindering progress. While they finally compied almost all of additional features of neovim, there is no sense of innovation and progress there and unfortunately the diff with neovim is right now minimal so neovim loses contributors that would otherwise be
Sort of like the Gnu Emacs / XEmacs split back then which divided the contributors. At least in case of Emacs one of these came on top, so there is no split anymore.
With Vim being such a complete and powerful piece of software that still receives useful yet light features and is extensible to a dizzying degree, it's hard to push vscode on programmers that want an efficient tool.
I tried vscode's remote capabilities. Ended up back on SSH/tmux/vim workflow. Ctrl-p file lookup was too slow, I like my shell, I didn't find the vscode terminal to be the best terminal experience
Help me understand more: what are "remote capabilities" wrt vscode?
I kicked the tires on vscode and atom and while I liked lots of things about them, it seemed like they were kinda overboard with memory consumption. These things are ultimately running web browsers, right? I'll probably have to give it another look.
It has vscode vim [0] which works well for default configurations, but it's not "actual" vim. I know with sublime text there is an actual-vim plugin [1] which lets you run neo-vim.
Competition is good and I'm glad we're having it.