Killersheep – Silly game to show off the new features of Vim 8.2
github.com
github.com
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.
For the rest of us normal users though, popup windows are terrific.
Edit: Or maybe only "officially" now with the new floating window API instead of having to roll your own code.
In any case I really appreciate what Neovim is doing to push Vim into adding features. I hope one day they converge into a single tool.
Where as before it was up to the plugin author to implement everything about it.
There's more details at: https://www.vim.org/vim-8.2-released.php
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.
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 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.
Thanks for all your hard work!
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.
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.
My response: use Emacs.
Tree Sitter ingratiation the next big feature actively being worked on.
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.
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.
[1]: https://github.com/neovim/neovim/wiki/FAQ#home-or-some-other...
[2]: https://github.com/neovim/neovim/wiki/FAQ#esc-in-tmux-or-gnu...
https://vi.stackexchange.com/questions/18768/highlighting-ta...
[0]https://mobile.twitter.com/neovim/status/1101893773561348096...
What’s the news on that front?
What are possible use cases?
Can't a plugin developer do this externally?
This also brings the question of why having a GUI?
why waste that time instead of using vim?
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`