Neovim 0.3 released
github.com
github.com
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.
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).
A lot of things "just work". Still, it still uses vim plumbing so it's quirky.
set mouse=""
and/or have a ~/.vimrc
So, for example, if you have autosave enabled, it won’t block the UI while it’s writing to disk.
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.
set clipboard+=unnamedplus
More details on that here: https://neovim.io/doc/user/provider.html#provider-clipboardA couple of small things I really like:
:set inccommand=nosplit
... this gives you a live view of substitutions as you type out a replacement e.g :%s/foo/bar/ :term
:vs term://bash
... these gives you a proper embedded terminal window inside vim.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
It also has a guicursor option for making the cursor display as a block or bar in the terminal depending on which mode you're in: https://neovim.io/doc/user/options.html#'guicursor'Other than that, there's a more thorough list of differences here: https://neovim.io/doc/user/vim_diff.html
:set inccommand=split
It's pretty cool, but I just prefer the nosplit way since it's less obtrusive. :)It ends up being similar in use to how many modern editors have multiple cursors.
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.
"In [terminal] mode all keys except <C-\><C-N> are sent to the underlying program. Use <C-\><C-N> to return to normal-mode."
:help terminal-emulator-inputTo 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.
- 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).
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.
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).
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.
I rarely notice any difference whatsoever in terms of behaviour.
That gives you MacVim's native Cocoa GUI while also using its console version as the system-wide vim.
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).
https://robots.thoughtbot.com/how-to-copy-and-paste-with-tmu...
Otherwise the "+y / "+p commands should yank and paste system clipboard correctly.
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.
I haven't found a single good GUI for nvim/vim. If you have, please let me know.
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.
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've had better luck with IDEs that have vim like features than projects that try to make vim into an IDE.
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.