Vim 8.2 | Hacker News Reader

Vim 8.2

vim.org

104 pointschrisbra8075 comments

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.).

Competition is good and I'm glad we're having it.

Yes, I didn't expect to see popup windows, which seems to a be a direct response to Neovim's floating windows (https://twitter.com/Neovim/status/1101879098044043264).

reminds me of clang/gcc

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.

This is more like egcs/gcc. Like egcs, neovim is also a fork motivated by the desire for a new governance model.

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?

I thought vim always was a «BDFL project», i.e. run by one person.

Run by one person doesn't mean developed by one person.

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 :-)

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.

May I interest you in https://github.com/neoclide/coc.nvim which let's you use some of the most popular bits of vs code in neovim

I use this with neovim, it is very nice. So far so good.

In the other direction the VSCodeVim plugin has options to experimentally use Neovim to power some vim features inside of VS Code.

https://github.com/VSCodeVim/Vim

> That said, I'm not switching back.

Me either.

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.

Here is another hacker news post discussing the backstory: https://news.ycombinator.com/item?id=12481084

Here is a bit of shade tossed on the Neovim project back in 2014 by Bram: https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

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!

https://github.com/vim/killersheep

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.

There are a lot of ways to skin this particular cat.

I've found vim-lsp is probably the best starting point, as you can plug any server you want into it, and have a consistent interface.

https://github.com/prabirshrestha/vim-lsp/wiki/Servers-Pytho...

What does it mean "plug in a server into it"? I looked at the page you linked to, and I have no idea what any of that means, or what to do with it.

I just want some basic stuff: autocomplete + indentation will probably achieve 90% of what I want from a Python IDE.

Check out coc aka Conquer of Completion

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.

[1] https://en.wikipedia.org/wiki/Language_Server_Protocol

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

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.

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.

Autocomplete, autoindentation, and perhaps colors would be nice though!

To me, the main advantage of vim over IDE is it's there on any remote server.

auto indent and syntax highlighting are there by default. Never used autocomplete so can't say.

I tried autocomplete in vim for Python a few years back, I forget which plugin. It was annoying, too aggressive. Uninstalled.

Afaik there’s basic autocomplete but only if vim was built with the python option enabled.

But then again I use vscode and pycharm in vim mode.

Ctrl-p is the shortcut for 'dumb' autocomplete in vim.

Shameless plug, I wrote Snake for Vim, which helps you configure Vim to be more flexible for writing code, using regular Python.

https://github.com/amoffat/snake

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.

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!

[1]: https://github.com/dense-analysis/ale

Ale is great - lints, checks, fixes - rules my world. A little complex to get going for multiple languages but when you do it's very powerful.

BTW worth checking https://github.com/justinmk/vim-dirvish as a lightweight alternative to NerdTree or netrw.

Oh wow, thanks for the tip. Gonna check it out.

I've been doing python development in vim for the past 8 years with no plugins. Works perfectly fine.

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.

«set list» will enable tab highlighting.

You Complete Me is pretty good for autocompleting python, c, c++ and c#. For python it doesn't need any set up.

> 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.

[0] https://github.com/python-mode/python-mode

[1] https://black.readthedocs.io/en/stable/

[2] https://github.com/kalekundert/vim-coiled-snake

[3] https://github.com/tpope/vim-fugitive

These actually seem to be exactly what I was looking for, thanks! What about files view in vim, like Nerdtree that someone mentioned below?

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 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.

So, given what you just wrote, why do you still use it?

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.

If you had used a plugin manager like Vundle, you could have simply uninstalled the plugin that's giving you trouble.

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.

https://www.vim.org/vim-8.2-released.php

This page is remarkably more informative than the commit diff, let's consider updating the url to this instead.

that wasn't there, when I noticed the commit

It's not a complaint about your post, just a moderation request. :)

The pink color of those popups is brutal.

Ok, we changed to that from https://github.com/vim/vim/commit/98056533b96b6b5d8849641de9.... Thanks!

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.

Not sure which point you're trying to make. Vim is hindering progress by progressing in all the areas that NeoVim was also progressing??

I don't see how vim can be hindering progress when it, along with emacs, is more powerful than the editors that 99% of other people are using.

With vscode recent remote capabilities its hard to push(come up with a argument) vim/emacs for programmers who do dev in remote VMs.

Does vscode have vim emulation or actual vim that runs plugins. If it's the former, your statement is ludicrous.

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.

[0] https://github.com/VSCodeVim/Vim [1] https://github.com/lunixbochs/actualvim

Yes, there's vim emulation. You can't run vim plugins but there are plugins that to the same as the vim ones.

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.

https://code.visualstudio.com/docs/remote/remote-overview

Hmm, that's interesting. I might just give that a try. Thanks for sharing!

Tramp mode (https://www.emacswiki.org/emacs/TrampMode) has been part of emacs for some time now.

How is it better than the good old remote deployment feature in Pycharm?

Pycharm still requires and assumes you have a local python environment.

I'm confused, is vscode not a local environment?

VS Code is local but I assume OP means with VS Code remote extensions you don't need Python locally.

Oh I see. Yes, it's a good point.

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

sshfs has been a thing I've used with any editor for at least a decade. Making it part of the editor itself instead of the file manager is bloaty.

Reply on news.ycombinator.com