I've avoided neovim because my current vim setup justworks™ and i trully depend on it for being productive on my job. As time goes by i really feel like i should switch based on how the two projects progress. Do you know of a resource that could hold my hand?
Well in theory everything that works in vim will work in neovim (there's a few exceptions[^1]). So you really don't loose anything by installing neovim and using your same .vimrc for it.
You can start experimenting with Lua and the new plugins whenever you're able to.
When I switched in 2018 my config essentially just worked, I had to replace a plugin that no longer worked but everything else went smoothly, the process took about ten minutes.
Err unless something has changed, everything that works in vim8 should work in neovim. It was a drop-in replacement for me. Nothing new to learn unless you're a plugin developer.
The exception is the async API which was first implemented by Neovim, but Vim followed with something incompatible. Most plugins that need it are compatible with both though.
I've been using MacVim for 15 years; it has been pretty much solid the entire time, and I'm used to its mouse integration. When I started out, I was doing a lot of cross-platform development and there was a Windows version of Vim which behaved almost the same. It was great to have a powerful text editing experience which was pretty much the same everywhere.
I tried out NeoVim, but as far as I can tell, it seems to be terminal-only/keyboard-only? I can use Vim keyboard-only (certainly I do that all the time over ssh), but it's not my preference.
My second choice for editing behind MacVim isn't NeoVim but VSCode, but I don't use VSCode with Vim bindings because in my experience grafting Vim bindings onto any editor not Vim won't be feature complete. In a perfect world, there would be an IDE which is truly a Vim-style modal editor at its core.
I just started looking into Neovim, and I had the same concern about it being terminal-only. But then I saw this on the Neovim site:
"Graphical interfaces are not packaged with Neovim. GUIs are not limited by terminal capabilities and can choose to override the rendering of certain neovim elements (cursor, tabline, popup menu, etc)...See Neovim's wiki[1] for a list of many of the available GUIs."
> This extension uses a full embedded Neovim instance, no more half-complete VIM emulation! VSCode's native functionality is used for insert mode and editor commands, making the best use of both editors.
I like lots of things about VSCode, but there are inefficiencies with editing that just drive me bananas so I keep falling back to good old familiar MacVim. For instance, line wrapping, auto-indenting, and mouse-select-then-rewrap in comments — comment support in the Vim ecosystem seems to have been designed by and for people who really care about good documentation, while I have to work much harder to get my comments and docs to look good when editing with VSCode.
Hopefully the mechanism of embedding a full NeoVim instance will allow for a moe-or-less feature-complete Vim editing experince.
There is also Onivim although it is not 1.0 yet. Development is financed through selling licenses but it is open source and you can build it yourself. Development has stalled when the main dev got a job some months but there are apparently still people willing to develop it.
Oni2 is not vim. It does not act like vim. It uses neither Vimscript nor Lua, but instead Javascript (VSCode-based extensions).
I paid for an Oni2 licence and regret it, because it isn’t what I want, which is a MacVim.app wrapper for neovim.
If you like MacVim.app, there is _absolutely no GUI that is acceptable_ for neovim. I understand why, and I’m not interested in taking on the development myself. But until someone makes a GUI that is as well-integrated with macOS as MacVim.app, I will be using vim and not neovim.
In addition to the fact that there are guis for neovim, neovim in the terminal does support mouse interaction as well (assuming your terminal emulator supports it, which should be the case for most modern terminals).
I just tried out nvim in the MacOS Terminal, and a couple of things didn't work right away.
First, clicking on a location didn't set the cursor. Especially when editing large files, I like to scroll in MacVim, click to set the cursor and then start typing. While I can do things like note the line number and jump, or scroll by moving the cursor with key commands, I find those less efficient.
Second, selecting text using the mouse didn't produce a selection that Vim knew about. I use this feature all the time in MacVim, to produce a visual selection which I then rewrap using `gq`, filter by piping the selection through an autoformatter like `rustfmt`, etc. Again, I can do this using keyboard navigation exclusively to make visual selections, but I find it easier to select using the mouse.
Interesting, all of those things work for me with alacritty, kitty, gnome terminal, etc. Maybe it is a limitation of MacOS Terminal? Or you need to explicitly enable `set mouse=a`?
This seems to be something in Vim rather than a NeoVim-specific setting, as I tried the same thing with the standard Vim and it worked the same. The scrolling feel in the Terminal isn't as smooth as MacVim, but it's still pretty good.
Yeah, there are a bazillion UIs (and most have stopped being updated) but nothing that comes with like vim/gvim. I might have looked at neovim if there was a neovim/gneovim but that isn't the case. I am okay with Lua. I am okay with Vimscript and Vimscript9. So neither of those is a pusher for me.
I've just installed it and started playing around.
On first open, a lot of the interface was unreadable because VimR seemed to be assuming a dark background, but I use a white background. `set bg=light` didn't fix it. `colorScheme=PaperColor` fixed it incidentally because it didn't find the color scheme and reverted to something legible, haha.
Next, I tried to set the font size for the navigator to something bigger because my eyes aren't that great. Although I can use `set guifont` to set the editor area font, the navigation area doesn't change. Presumably there's some way to fix it, I just haven't found it yet.
VimR looks cool and I really like having the navigator there IDE-style, but it seems like there will be a period of adjustment. Nothing new for someone accustomed to Vim, haha.
The main IDE-style features I've been going without in my ordinary day-to-day editing with MacVim are the autocompletion, suggestion, and hover-to-show-documentation. (I've started using ALE which is helpful but needs some tweaking before it's really usable.) It might be possible to get those with either MacVim or NeoVim, and it would be worth the configuration to set them up if so.
Have you tried coc? Despite the repo name it works with regular vim too and is definitely the easiest way to get completion and other LSP functionality (jumping to definitions, doc previews, error highlighting etc).
I have set up a complex neovim configuration, but I don’t use it.
Why? Because there’s not a _single_ neovim client that is as good as MacVim.app. I paid for Oni2 (I regret that; it’s _not_ a vim replacement). I have contributed code and time to helping a couple of other GUIs fix their issues. But they are all crap compared to MacVim.app.
Until that is fixed, I don’t think that there’s a good reason to consider switching.
I tried it. For various reasons, it isn’t _quite_ there.
It doesn’t build a .app bundle, which means that it can’t have a proper distribution with appropriate signing &c. that would give it access to various macOS features. It doesn’t have a menu (which _does_ matter).
It doesn’t have a "release" build since May 2020, meaning that the only way to get a meaningful build is to build it yourself (not a big deal, but still).
I have the same setup in both vim8 and neovim. It's symlinked over from neovim, because I like the xdg ~/.config dir better, keeps things tidier. Basically pathogen, lightline and vim polyglot. I use vim8 most if the time out of habbit. I like Lua better but I understand it has poor handling of strings and I don't know how that fares with and editor extension language.
> it has poor handling of strings and I don't know how that fares with an editor extension language.
I guess the parent refers to Lua treating strings as simple byte arrays, whereas a text editor has to deal with characters in various encodings, some of which can be multi-byte.
