Neovim 0.3 released(github.com)
github.com
Neovim 0.3 released
https://github.com/neovim/neovim/commit/44c6deb91ac917703c157d564eb3accbff4d37af
61 comments
You have any experience with ActualVim? Does it hold up for actual work or is it still in an experimental phase?
I'm the author. ActualVim feels pretty slick out of the box. The main issue is in parts of the Vim UI that aren't integrated yet (I'm praying for more UI customization options from Sublime Text, though the recent command palette improvements should be a great start for replacing the command line).
The actual editing should be really solid, even if you use Sublime Text features to manipulate text. It's typically very fast too, I try to beat 16ms handle time per keystroke on all platforms (so updates land within a frame).
The actual editing should be really solid, even if you use Sublime Text features to manipulate text. It's typically very fast too, I try to beat 16ms handle time per keystroke on all platforms (so updates land within a frame).
That sounds awesome. I'm currently working with Emacs + Evil mode, but there's a couple of things I'm not thrilled with. Sublime with a NeoVim backend sounds like it could work great. I'll check it out!
Yay! I wrote stdpath()!
Neovim is a breath of fresh air compared to Vim
A lot of things "just work". Still, it still uses vim plumbing so it's quirky.
A lot of things "just work". Still, it still uses vim plumbing so it's quirky.
As someone who uses regular Vim as a (fairly modified) daily driver, can you explain what NeoVim brings to the table? My main gripe with Vim is that system clipboard support on my copy doesn't work, and without custom compilation, the only version it really works in is GVim, which I find kind of distracting.
Clipboard seems to work well for me with this config:
A couple of small things I really like:
Also, I think vim8 has it as well, but something people might not realise is you can use truecolor gui color schemes (not limited to 256 color) in the terminal with
Other than that, there's a more thorough list of differences here: https://neovim.io/doc/user/vim_diff.html
set clipboard+=unnamedplus
A couple of small things I really like:
:set inccommand=nosplit
:term
:vs term://bash
Also, I think vim8 has it as well, but something people might not realise is you can use truecolor gui color schemes (not limited to 256 color) in the terminal with
:set termguicolors
Other than that, there's a more thorough list of differences here: https://neovim.io/doc/user/vim_diff.html
Vim has termguicolors since a couple years now. Not sure about the other stuff, but Bram's been copying a lot of nvim's exclusive features it seems.
Whoa, I had no idea about inccommand. I just tried and it's amazing. Thanks!
When you test it out, make sure you try:
It ends up being similar in use to how many modern editors have multiple cursors.
:set inccommand=split
It ends up being similar in use to how many modern editors have multiple cursors.
My pet favorite: opening a terminal in a vim split.
Having an interactive bash/ipython/repl session where you can use vim keys to navigate and yank lines from your scrollback is pure bliss.
I like to run builds and be able to see, yank, open files from the errors all inside vim.
Having an interactive bash/ipython/repl session where you can use vim keys to navigate and yank lines from your scrollback is pure bliss.
I like to run builds and be able to see, yank, open files from the errors all inside vim.
> I like to run builds and be able to see, yank, open files from the errors all inside vim.
You can do something like this with the :grep or :make commands with the resulting preview window. Even if you were to do something like :r !make, you can view the errors by moving your cursor to the file name and pressing ctrl-w ctrl-f (to open in a new split window) or ctrl-w gf (to open it in a new tab).
You can do something like this with the :grep or :make commands with the resulting preview window. Even if you were to do something like :r !make, you can view the errors by moving your cursor to the file name and pressing ctrl-w ctrl-f (to open in a new split window) or ctrl-w gf (to open it in a new tab).
Why did it take VIM so long to get this? Emacs has this feature for 30 years or so.
It's a very emacsy idea. I think, for better or worse, vim is centered around the goal of making a better editor. Emacs is centered around making a portable universe.
To be honest, I don't really like having a 'terminal' in vim. It makes more sense to just use the terminal, which is like, right there, one ctrl-z away.
To be honest, I don't really like having a 'terminal' in vim. It makes more sense to just use the terminal, which is like, right there, one ctrl-z away.
I don't like Neovim's terminal mode because I need a terminal. I'm also a religious ctrl-z user. I use it when I want to be able to yy stuff out of the scrollback to use in the split with my code like parts of a live repl session or the output from curl.
vim used to have this listed in :help design-not
- Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"
In summary, it took it so long to get it because it explicitly goes against the original design (and I kind of think it was the right choice. Emacs already exists).
- Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"
In summary, it took it so long to get it because it explicitly goes against the original design (and I kind of think it was the right choice. Emacs already exists).
Tmux solves that problem and most power vim users use tmux
I honestly think this is a bit of a misfeature. Tmux provides the same functionality and the resulting hierarchy of responsibilities between your terminal apps seems more correct to me.
Terminal mode is awesome when combined with the quickfix feature. You can use :make and :grep without blocking the editor.
I use nvims terminal because.
1. I don't want to learn a bunch of new key bindings to switch between terminal and editor windows. With nvim, I can use the same process that I use to switch between buffers, to switch to a terminal window.
2. I can use the same process to copy to/from terminal/buffer windows, and use the full range of vim registers in the process.
3. I can name terminal buffers in the same way I name editor windows, and use the names to switch to the terminal window.
1. I don't want to learn a bunch of new key bindings to switch between terminal and editor windows. With nvim, I can use the same process that I use to switch between buffers, to switch to a terminal window.
2. I can use the same process to copy to/from terminal/buffer windows, and use the full range of vim registers in the process.
3. I can name terminal buffers in the same way I name editor windows, and use the names to switch to the terminal window.
How does one get back to "terminal content as a buffer" from the interactive version of the terminal?
from: https://neovim.io/doc/user/nvim_terminal_emulator.html
"In [terminal] mode all keys except <C-\><C-N> are sent to the underlying program. Use <C-\><C-N> to return to normal-mode."
"In [terminal] mode all keys except <C-\><C-N> are sent to the underlying program. Use <C-\><C-N> to return to normal-mode."
This and more is explained in the doco.
:help terminal-emulator-inputFor me neovim brought true color themes support in the terminal, which was a breath of fresh air, or rather a major relief for my eyes. I switched to it for that reason, and using it ever since.
The main benefit of Neovim for me is support for async jobs.
So, for example, if you have autosave enabled, it won’t block the UI while it’s writing to disk.
So, for example, if you have autosave enabled, it won’t block the UI while it’s writing to disk.
Vim now also supports async jobs since Vim 8 (but with a different API).
IIRC, neovim implementation was first proposed as a vim PR before the fork happened. The mess following it was one of the main reason behind the fork.
IIRC, neovim implementation was first proposed as a vim PR before the fork happened. The mess following it was one of the main reason behind the fork.
At this point, vanilla Vim has async jobs as well, although it's not as clean as NeoVim
can you expand a bit more on "not as clean" as NeoVim? I consider vim's implementation of async jobs simpler than neovim's.
A working workaround for me was to alias vi to `gvim -v` instead. It launches gvim without the GUI (so... vim), but still keep clipboard support.
Taking a stab, but you're not using Vim under tmux on a Mac, are you? If so, you need to do a tweak to get clipboard access.
https://robots.thoughtbot.com/how-to-copy-and-paste-with-tmu...
Otherwise the "+y / "+p commands should yank and paste system clipboard correctly.
https://robots.thoughtbot.com/how-to-copy-and-paste-with-tmu...
Otherwise the "+y / "+p commands should yank and paste system clipboard correctly.
The differences are very small. I use both, nvim for programming, and vim for everything else. This is for no real reason - it's just turned out that way. Some programming-related plugins I use work better on neovim, although there are also some where it's smoother sailing on vanilla.
I rarely notice any difference whatsoever in terms of behaviour.
I rarely notice any difference whatsoever in terms of behaviour.
You don't need to compile vim for clipboard support these days. On Mac, `brew install vim`, on Ubuntu `apt-get install vim-gtk`. The latter I think comes with the gui version of vim but you don't have to use it, it also includes a `vim` binary with clipboard support.
On Mac, for regular Vim I recommend `brew install macvim --with-override-system-vim`
That gives you MacVim's native Cocoa GUI while also using its console version as the system-wide vim.
That gives you MacVim's native Cocoa GUI while also using its console version as the system-wide vim.
That's a good idea, but only for those who need to have full XCode installed. If you only have XCode Command Line Tools installed, I think it's better to just use console vim + tmux.
I wasn't aware you needed full XCode. That is a burden.
You can also brew cask install macvim and symlink the console exe from within the .app bundle (which is essentially what the regular brew formula does as well).
You can also brew cask install macvim and symlink the console exe from within the .app bundle (which is essentially what the regular brew formula does as well).
Can't answer about copy/paste an NeoVim, but I just switched from vim -> neovim this week, and do feel it's a bit snappier. I also switched from syntastic to ALE for syntax checking and that made a huge difference as well.
For copy/paste in the terminal and vim, I usually have vim in a tmux session, and that has a few helpers to work with system clipboards. Not perfect, but better than vanilla vim's copy/paste.
For copy/paste in the terminal and vim, I usually have vim in a tmux session, and that has a few helpers to work with system clipboards. Not perfect, but better than vanilla vim's copy/paste.
Re: your clipboard issues, which platform are you running on? I am using vim+iTerm2 on OSX and vim+st on OpenBSD and the clipboard integration works flawlessly.
I suspect vim on Debian Stretch, which now ships with "please break selection mechanisms" as a default. The fix is
set mouse=""
and/or have a ~/.vimrc
set mouse=""
and/or have a ~/.vimrc
it's slightly faster to start up, is a big one
You should probably substantiate such a bold claim with a few comparative examples. I have yet to encounter a situation where vim doesn't "just work".
For the record, I don't think nvim is much better, but there's definitely stuff that doesn't work out of the box in Vim. For instance, the Alt key was a real struggle for me. Clipboard support is the same for a lot of people. Both of these things are for reasons, but still.
No thank you.
I have a serious question: If Emacs has a lot of the features people seek in Neovim, why not just use Emacs in evil mode? I watched this earlier today so it seemed relevant: https://youtu.be/JWD1Fpdd4Pc
Side note: I've been using Neovim for months now and I've not tried Emacs. Not because I don't want to but because Vim with the plugins i have works really really well.
Side note: I've been using Neovim for months now and I've not tried Emacs. Not because I don't want to but because Vim with the plugins i have works really really well.
Evil mode doesn't support most ex mode commands. Can be jarring for someone used to doing things the vim way. Eg :help is just a thin wrapper around emacs' native help system, no :sets work, :u isn't implemented, etc.
I wish there was a good GUI for nvim/vim. I've tried them all and they all lag, either just a cursor lag when there is syntax-highlight (gvim) or when using snippets/auto-complete (nvim-qt for example).
I haven't found a single good GUI for nvim/vim. If you have, please let me know.
I haven't found a single good GUI for nvim/vim. If you have, please let me know.
Oni is pretty slick, and development is very active: https://github.com/onivim/oni
I've just switched to Oni, and would highly recommend it for someone who wants a Vim with the best features of modern graphical editors like Visual Studio Code. Oni does have some rough edges, since it's still pre-1.0, but it is largely feature-complete, with Language Server Protocol support, lightning-fast search powered by ripgrep, a command palette etc.
ActualVim is a Neovim frontend implemented as a Sublime Text plugin. It uses Sublime's syntax highlighting, and can use Sublime's native snippet UI as well.
According to the README of that project, it does not support snippets nor auto-complete yet. Seems to be very alphaish..
Not snippets/completion, very specifically "[Sublime's] Auto-popups while typing". This is due to the way I intercept Sublime's input.
Vim's snippets/completion work fine, and Sublime's work fine if you invoke them in another way.
See https://github.com/lunixbochs/actualvim/issues/97 for the planned fix.
Of the main caveats:
- No multiple cursors is due to lack of support in neovim, it's blocked on either neovim implementing them or me emulating them
- No "Auto-popups while typing" is due to a limitation in Sublime's input system, which I plan to work around if they don't provide another first-party solution.
- Undo coalescing isn't a major issue unless you switch modes repeatedly, because Vim's undo works fine.
- Surfacing more of Vim's UI is slowly happening as neovim adds more UI APIs.
- "Extremely large files" is fixed in master for nvim->Sublime buffer changes with neovim 0.3's change deltas. It's not completely fixed for Sublime->nvim buffer changes (like if you run a host plugin or click a Sublime UI element), because Sublime has no delta system. #97 plus a C diffing library would sort that out, as would Sublime adding a change delta API.
Vim's snippets/completion work fine, and Sublime's work fine if you invoke them in another way.
See https://github.com/lunixbochs/actualvim/issues/97 for the planned fix.
Of the main caveats:
- No multiple cursors is due to lack of support in neovim, it's blocked on either neovim implementing them or me emulating them
- No "Auto-popups while typing" is due to a limitation in Sublime's input system, which I plan to work around if they don't provide another first-party solution.
- Undo coalescing isn't a major issue unless you switch modes repeatedly, because Vim's undo works fine.
- Surfacing more of Vim's UI is slowly happening as neovim adds more UI APIs.
- "Extremely large files" is fixed in master for nvim->Sublime buffer changes with neovim 0.3's change deltas. It's not completely fixed for Sublime->nvim buffer changes (like if you run a host plugin or click a Sublime UI element), because Sublime has no delta system. #97 plus a C diffing library would sort that out, as would Sublime adding a change delta API.
Evil or Spacemacs in Emacs? 26.1 with pixel-level scrolling out now!
Not really a frontend on Vim or NeoVim though are they? They’re emulations which are very nice but not the real thing.
It’s the uncanny valley situation again. For example, in Vim, like all terminals by default you can use C-h as backspace. In Emacs though that’s bound to help.
So now I have to rebind that and make a decision on what should now be help. That’s just the start on the thread pulling and tweaky just to get back to my expected behaviour.
Emacs is great but it’s not Vim. You could argue thatonce configured you have all the new power of Emacs but ome of just want a better Vim. Not Emacs. Even if it’s brilliant.
It’s the uncanny valley situation again. For example, in Vim, like all terminals by default you can use C-h as backspace. In Emacs though that’s bound to help.
So now I have to rebind that and make a decision on what should now be help. That’s just the start on the thread pulling and tweaky just to get back to my expected behaviour.
Emacs is great but it’s not Vim. You could argue thatonce configured you have all the new power of Emacs but ome of just want a better Vim. Not Emacs. Even if it’s brilliant.
NeoVim is not quiet Vim which isn't vi either and all are terminal editors first so GUIs may never be as good for them. When I started with Emacs I thought I might use it in the terminal after Vim vs GVim but it's GUI is worth it.
I wasn't long enough using Vim to depend on C-h but if you've the time for all the config it's great to have the options. That reminds me I must still make so changes to Vim Vixen to be more like Vimperator was. It's great having the basic vim commands in Emacs as well, maybe not in org-agenda.
I wasn't long enough using Vim to depend on C-h but if you've the time for all the config it's great to have the options. That reminds me I must still make so changes to Vim Vixen to be more like Vimperator was. It's great having the basic vim commands in Emacs as well, maybe not in org-agenda.
I can specifically recommend doom-emacs.
I've tried all of them as well. gvim is the most performant non-terminal based vim.
I've had better luck with IDEs that have vim like features than projects that try to make vim into an IDE.
I've had better luck with IDEs that have vim like features than projects that try to make vim into an IDE.
And there were recently some fixes for Konsole to work with DECSCUSR, so neovim won't need special hacks for it.
Ubuntu launchpad repo is still on 0.2,
https://github.com/lunixbochs/ActualVim/commit/414e8d4c3feb4...
Oni[1] is also expected to use the feature soon.
Other features worth noting are
- <Cmd> key https://github.com/neovim/neovim/pull/4419
- stdpath() function https://github.com/neovim/neovim/pull/6272
https://github.com/neovim/neovim/pull/7679 and https://github.com/neovim/neovim/pull/8226 are small but nice quality-of-life improvements.
There's also many new API features and defaults tweaks listed in the release notes.
Oh, and a built-in AST-producing VimL expression parser:
https://github.com/neovim/neovim/pull/7234
That's a big one.
[1] https://github.com/onivim/oni