Imagine not having a full screen spell check suggestion window, but instead a little context menu that pops up where you can pick a suggestion while still being able to read the original buffer that you're trying to spell check. Sort of like what Sublime Text had forever.
Or little snippets of helpful text for git specific details or inline documentation for auto-complete.
I've only been using Vim for about 8 months but floating windows is something you severely miss having previously used other editors like VSCode. Now with them in tact, it will unlock all sorts of great features and UI wins. I wonder how long it will take for plugins to start adopting it.
I'm a newbie vim user, but my friends and colleagues that have been using it for years have been professing for years that floating windows are a distraction. That part of vim's appeal is the raw and undisturbed viewport. Not now though. These floating windows are like the second coming.
It's a preference. These have been available for Emacs in various forms for a while but I much prefer side info (from lsp and the like) to pop up in another buffer and only when I ask for it.
Popup menus have been a thing since long time ago. Nvim floating windows are true arbitrary windows (they are placed in floating layers over other windows and then composited within the grid; in more flexible UIs they can be handled independently); I assume vim 8.2 floating windows are more or less the same.
Would CTRL+X + CTRL+p/l/f be something akin to this? I use these frequently and have been quite content with their ability to provide in context completion.
Emacs has a z-machine interpreter. You can run Anchorhead under Emacs. Also, it has a inform-mode to code your own games, too.
Also, it could be possible to create an altair 8800 emulator with not so many CPU fastness issues.
I switched to neovim about six years ago because completion backed by language servers was unusably-slow without neovim's asynchronous support. That was added to Vim in 8.0, and since then, there's been no difference between the two for my workflow. I use the same config for both Vim and neovim (save for a couple minor unimportant tweaks).
I don't think there's a compelling reason for many people to switch to neovim right now. I appreciate that the appearance of neovim was a real kick in the ass and prompted improvements in Vim. Vim had been essentially stagnant with no new features for a decade. It's now got frequent releases and tracks neovim's improvements closely. neovim's existence continues to improve Vim itself through innovation and competitive pressure.
I value neovim for how it's revitalized the Vim community, and I still use it mostly because while there's no reason for me to switch to neovim these days, there's also no reason to switch back.
As part of the neovim team and the author of the built in LSP for Neovim, I'd say that 0.5 is where things will really diverge. One of those factors is the built-in LSP support, but the others are the ramping up of Lua plugins being written, the extranges/extmarks features being worked on, the treesitter integration, and some other features I won't mention for fear of drumming up premature hype.
I completely agree with you otherwise. Neovim inspired Vim/Bram to kick things back into gear, and Neovim also took some inspiration from Vim's ideas, and the two have been close for a while, but the Lua integration is beginning to pay dividends which will cause a wider rift. Vimscript is not an ergonomic programming language or very performant compared to Lua, and I'm pretty sure that everyone can agree with that.
E: Oh, and I plan to make an answer to KillerSheep for the 0.5 release that will hopefully be equally or more impressive. :P
I'm looking forward to that. I've written a few plugins. Vimscript is fine for some stuff, but you can only do so much with it. I got deep enough in that I uncovered a bug with autoloaded dictionary functions. I wrote a pretty extensive unit test library for vimscript too, but then I threw in the towel and started writing plugins using Ruby and Python. Those were still pretty slow.
I'm grateful to Bram for all he's done with Vim, but there are many inefficiencies in it, and the Vim source is extremely hard to work with and not well-factored. Just having neovim as a rewrite that's easier to modify is great.
Maintainer, not maintainers. If you look at the vim repo, https://github.com/vim/vim, essentially all commits are from the same person. Encouraging contributions and splitting maintenance between multiple people was one of the key factors when forking neovim. IIRC neovim was a result of Bram, the vim creator, refusing a PR for async plugins. Functionality that is today regarded as extremely important.
Lots of people have migrated. Some have migrated back. Neovim is developing at a good pace, porting features from some of its GUI clients to the TUI. Some of the features that set it apart have been reimplemented and landed in upstream Vim. As such, plenty of plugins are portable across both editors. Personally, I’ve stuck with Neovim since I switched.
My config in vim and neovim is also identical. I literally downloaded neovim and just copied over my ~/.vimrc to ~/.config/nvim/init.vim and kept rolling.
The config path is different, perhaps that was it? Or maybe an award installation a few years ago. I remember having a few minor issues with pip, due to unfamiliarity with it. Some python version shenanigans as well. These days I can't really imagine any of those being an issue.
NeoVim is still under very active development. I switched a few years ago and have yet to feel any need to switch again -- though with Vim 8 there is less of a strong argument to switch away from Vim if you're already using it.
I view it as a Perl 5/Perl 6 thing. I don't want to invest in Vim, because supposedly Neovim is the future. I don't want to invest in Neovim, because it's still being developed, and with the way plugins are created using Message Pack, it seems like it has to be slow. My response: do other things with my time.
Please note that there is no longer a Perl 5 / Perl 6 thing, as Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). How this would apply to the Vim / Neovim situation, I'm not sure. With regards to slowness: over the past years, Raku has gained orders of magnitude in speed in almost all areas of the system.
> How this would apply to the Vim / Neovim situation, I'm not sure.
Because year after year, the new version of Perl was supposedly on the way. After they pretty much killed the language by having a new version that wasn't ready and nobody wanting to invest in the old version, they decided to salvage what they could of their userbase. I'm seeing an exact repeat (from the view of outsiders) with Vim.
There are a lot of differences between vim/neovim and perl 5/6:
1. When Neovim came along, vim had stagnated. Many features (notably async) in vim 8 probably would not be there if neovim didn't exist.
2. Neovim is "ready". The only feature classic vim has that is really missing from neovim is a really solid GUI (or maybe I just haven't found it yet). And at least for me, the TUI features make running it in a terminal fine.
3. Neovim has a very high level of compatibility with classic vim. Migrating from vim to neovim generally doesn't require changing the config very much if it all. Most plugins work on both. Many patches from vim are carried over to neovim, etc. It's even possible to use the same config for both neovim and classic vim, so you can easily switch between them.
The biggest concern, I think, is that there is some divergence in the APIs for new features, which requires a little bit more work for plugin maintainers to support both. And without any real dependency system for plugins, it's more complicated to distribute a compatibility layer. (and polyfills are impossible since you can't have all-lowercase user-defined function names in vim)
At this point you can mostly think of neovim and classic vim as two implementations of the same thing. Both are innovating, and ideas are shared between them, but sometimes they have slightly different APIs for new or experimental features, but hopefully those apis converge over time.
Actually the Neovim development is moving at least several orders of magnitude faster than Perl6 was. And it's not "the next version" of Vim. It's an ambitious effort to improve on Vim whitout rewriting the whole thing like it happened with Perl6/Raku. "Nobody wanting to invest in the old version" is also a bit overblown.
But that really isn't a great selling point relative to extending my editor using, say, Emacs Lisp. The bit I've looked at Vimscript made me conclude it's best to use the editor as it's designed rather than put together rather ugly code.
Neovim has a lot more features. Neovim's equivalent of popups are floating windows, they are just normal windows so they can be harder to configure, but the end result it better.
Tree Sitter ingratiation the next big feature actively being worked on.
I prefer neovim because it has a more active developer community (487 contributors vs. 2).
I have more trust in the strength of a community to go on developing it. In case something happens to the vim contributor(s) - e.g. one is struck by a lightning and the other one gets sick for a long time then it will be difficult to maintain it.
As long as everything works fine I didn't have any reason to try vim again. Though I am happy to see they move forward as well.
I switched to Neovim last week (from vim) and it was pretty painless.
mkdir -p $HOME/.config/nvim
cat >> $HOME/.config/nvim/init.vim << __EOF__
set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
source ~/.vimrc
__EOF__
And it just uses my vim configuration and plugins. The "default" colorscheme rendered slightly differently than vim for me, so I messed around to find a new colorscheme that did what I wanted.
I had to fix my .screenrc in a handful of ways for neovim:
* I had it set to pretend to be xterm ('term xterm'), but that confuses neovim quite a bit.[1] Additionally, terminology (the term emulator I use) sets XTERM_256_COLORS, which confuses neovim into thinking TERM is xterm. So I added 'unsetenv XTERM_256_COLORS' in screenrc as well.
* Also, I had to add 'maptimeout 1' to allow Esc to leave insert mode as quickly as it did in vim, when running nvim under screen.[2]
That's about all I've done to switch. The existing plugins I had all worked out of the box.
I switched when neovim was only a year old, just to see if my vim environment spun up without issue, and it did. Then the async linting won me over, and I've never looked at vim again. I'm less excited about the stream of new features than I am about a dev community that's less BDFL focussed. I'm looking forward to using lua for plugins as an entry point to get more involved in neovim development. Getting into the vim developer community just seems a lot... more difficult.
I looked up a Twitter demo of how the new floating window feature is going to be used [0] and my only reaction is "I hope this doesn't get used by any core feature of the editor in the future". There's something about an always moving visual element that isn't directly under my control that feels extremely uncomfortable to me and is something I honestly didn't expect in vim. One of my favorite things about it has always been that it took up about two columns and a row of space to display anything that wasn't the file being edited.
In theory the two editors are closer in features than they have been in the past but in practice neovim feels like a superset with unique plug-ins and a more active community of people working on them.
Just use Emacs with evil mode, much better editing experience and you have all these features already. For ones you don't, just code it up in a few functions.
That's a fair point, but this situation rarely occurs because someone else likely has already written those functions before you, and adding it into emacs is as easy as `M-x package-install; PACKAGE`
Imagine not having a full screen spell check suggestion window, but instead a little context menu that pops up where you can pick a suggestion while still being able to read the original buffer that you're trying to spell check. Sort of like what Sublime Text had forever.
Or little snippets of helpful text for git specific details or inline documentation for auto-complete.
I've only been using Vim for about 8 months but floating windows is something you severely miss having previously used other editors like VSCode. Now with them in tact, it will unlock all sorts of great features and UI wins. I wonder how long it will take for plugins to start adopting it.