|
|
Subscribe / Log in / New account

New features in Neovim 0.5

August 3, 2021

This article was contributed by Ayooluwa Isaiah

Neovim 0.5, the fifth major version of the Neovim editor, which descends from the venerable vi editor by way of Vim, was released on July 2. This release is the culmination of almost two years of work, and it comes with some major features that aim to modernize the editing experience significantly. Highlights include native support for the Language Server Protocol (LSP), which enables advanced editing features for a wide variety of languages, improvements to its Lua APIs for configuration and plugins, and better syntax highlighting using Tree-sitter. Overall, the 0.5 release is a solid upgrade for the editor; the improvements should please the existing fan base and potentially draw in new users and contributors to the project.

The Neovim project was started by Thiago Padilha in 2014 shortly after his patch to introduce multi-threading capabilities to Vim was rejected without much in the way of feedback. This event was the major trigger that led Padilha to create this fork, with the explicit aim of improving the usability, maintainability, and extensibility of Vim while facilitating a more open and welcoming environment.

A built-in LSP client

The Language Server Protocol is an open-source specification that standardizes programming language features across different source code editors and integrated development environments (IDEs). It facilitates communication between code-editing tools (clients), and locally running language servers to provide language-specific smarts such as auto-completion, find-and-replace, go-to-definition, diagnostics, and refactoring assistance.

Prior to the development of LSP, the work of providing support for a programming language had to be implemented for each IDE or text editor, either directly in the code, or through its extension system, which led to varying levels of support across language and editor combinations. The LSP standard enables the decoupling of language services from the editor into a self-contained piece so that language communities can concentrate on building a single server that has a deep understanding of a language. Other tools can then provide advanced capabilities for any programming language simply by integrating with the existing language servers.

While it was already possible to use LSP in Neovim with the help of third-party plugins, the 0.5 release adds native LSP support to Neovim for the first time. The introduction of LSP in Neovim allows the editor to act as a client, informing a language server about user actions (such as executing a "go-to-definition" command); the server answers the request with the appropriate information, which could be the location of the definition for the symbol under the cursor. That will allow the editor to navigate to the specified location in the file or project.

The interface provided by the Neovim LSP client is a general one, so it does not support all of the features that are available in third-party LSP plugins (e.g. auto-completion). It was built to be extensible, though, so it includes a Lua framework that allows plugins to add features not currently supported in the Neovim core. Setting up individual language servers for the editor can be done using the nvim-lspconfig plugin, which helps with the launching and initialization of language servers that are currently installed on the system. Note that language servers are not provided by Neovim or nvim-lspconfig, they must be installed separately. There is a long list of LSP servers supported by the nvim-lspconfig plugin.

Lua integration

Initial support for the Lua programming language in Neovim landed in the 0.2.1 release in 2017. It has seen continued development and deeper integration in the editor since then, most notably with the addition of a Neovim standard library for Lua in the 0.4 release in 2019. The Neovim developers expect Lua to become a first-class scripting language in the editor, thus providing an alternative to VimL, which is the scripting language inherited from Vim. Neovim 0.5 takes big strides toward the realization of this goal by improving the Lua API and adding init.lua as an alternative to init.vim for configuring the editor.

A good explanation of the rationale behind the decision to embed Lua in Neovim can be found in a video of a talk by Justin M. Keyes, a lead maintainer for the project. In summary, Lua is a more approachable language than VimL due to its simplicity and ease of embedding. It is also an order of magnitude faster than VimL. Neovim supports Lua 5.1, which was released in 2006, rather than more recent versions of Lua, such as 5.3 or 5.4 (released 2015 and 2020 respectively), mostly due to LuaJIT, which only supports Lua 5.1. The motivation for maintaining compatibility with LuaJIT stems from its significant performance advantages over the standard Lua compiler.

Adding Lua to Neovim has made it easier to extend the capabilities of the editor and contribute to its core code, especially for users who have been put off by VimL, which is not a language that is used outside of Vim. Since Lua is also heavily used for scripting video games and for extending other programs written in a variety of languages (C, C++, Java, etc.), there is an abundance of resources available for learning the language, along with examples that show how to use it to interact with APIs from other languages. This wealth of information on Lua makes it possible for new plugin authors and aspiring Neovim contributors to get up to speed with the language quickly.

The Lua support in Neovim has led to it becoming the preferred language for how newer Neovim features, such as the LSP client, are being exposed. Using these APIs can only be done with Lua, since VimL cannot be used to interact with them. However, VimL support in Neovim is not going anywhere, and the Neovim developers do not anticipate any reason to deprecate it, so migrating an existing init.vim configuration to init.lua, or porting a VimL plugin to Lua for the sake of it is completely optional at this time. The only caveat is that using these Neovim APIs (such as LSP or Tree-sitter) in an init.vim configuration or VimL plugins can only be done by embedding some Lua snippets within the existing VimL code.

Although deeper Lua integration is seen as one of the main achievements of the 0.5 release, not all of the reactions toward the push to supplant VimL in the editor core have been positive. There is some concern that the emphasis on Lua APIs, and Lua-only plugins, will lead to a split in the plugin community where an increasing number of plugins will be Neovim-only (as opposed to supporting both Vim and Neovim). Also, an improved and not entirely backward-compatible version of VimL (currently referred to as Vim9) is under active development by Vim creator Bram Moolenaar and other Vim contributors. It is not entirely clear whether the Neovim maintainers plan to support Vim9, since they are more invested in Lua. At the time of this writing, there are already several Lua plugins that work only in Neovim, and a handful of Vim9 plugins that work only in Vim. It is therefore easy to speculate that the ecosystems for both projects may diverge significantly in the near future as there are currently no plans to bring a similar level of Lua integration into Vim.

Tree-sitter

Tree-sitter is a new parsing system that aims to replace the limited, regular-expression-based, code-analysis capabilities that are prevalent in current developer tools. It is a high-performance parser generator that can build parsers to create an incremental syntax tree for a source file, and can efficiently update the syntax tree in realtime as the file is being edited. In Neovim 0.5, support for Tree-sitter has been added to the editor core, although it is currently classed as experimental due to some known bugs along with performance issues for large files. The expectation is that it will become stable in the next major release (0.6), which should be expected in a year or two judging from past releases.

Using Tree-sitter in Neovim makes it possible for the editor to understand the code in a source file as a tree of programming language constructs (such as variables, functions, types, keywords, etc.), and use that information to handle those constructs consistently. When a Tree-sitter parser is installed and enabled for a specific language, the editor's syntax highlighting will be based on the syntax trees it provides; this results in improvements to the use of color to outline the structure of the code more clearly. In particular, object fields, function names, keywords, types, and variables will be highlighted more consistently throughout the file.

Tree-sitter is also able to do incremental parsing, which keeps the syntax tree up to date as the code is being edited. This puts an end to the practice of re-parsing an entire file from scratch in order to update its syntax highlighting after a change is made, which is currently the case with regular-expression-based highlighting systems. That leads to significant speed improvements.

Tree-sitter has been lauded for its improved syntax-highlighting capabilities, but it also enables the definition of language-aware text objects better suited to editing code than what is provided by default in the editor. The nvim-treesitter-textobjects module allows the creation of text objects for constructs like classes, functions, parameters, conditionals, and more, which can be manipulated just as easily as words or sentences. Several examples of the Tree-sitter-based highlighting can be seen in the gallery for the nvim-treesitter repository.

Wrapping up

The features above make up the bulk of this release, but Neovim 0.5 also includes improvements and bug fixes to the user interface, as well as smaller features such as support for remote plugins written in Perl 5.22+ on Unix platforms. It is also worth mentioning that around 1000 Vim patches were merged in this release, updating various aspects of the editor. The full list of changes, fixes and refinements can be seen in the release notes linked above.

The Neovim project uses GitHub issues to track all feature and bug requests, so a list of closed issues for the 0.5 milestone is available for a further exploration of the changes that made it into this release. The planning for subsequent releases is detailed on the project's roadmap page, while priorities are tracked through GitHub milestones. Contributions from the community are welcome, of course, and the project maintainers may be reached via Gitter, Matrix, or the #neovim room on irc.libera.chat.


Index entries for this article
GuestArticlesIsaiah, Ayooluwa


to post comments

New features in Neovim 0.5

Posted Aug 4, 2021 16:22 UTC (Wed) by flussence (guest, #85566) [Link] (9 responses)

One last thing Neovim needs before I'm comfortable uninstalling Vim is a single canonical replacement for GVim, hopefully before the distro I'm on finishes breaking GVim's gtk2 support, as the gtk3 port is an inferior half-baked mess.

The official docs point to this list on the wiki, but it looks more like a graveyard.

New features in Neovim 0.5

Posted Aug 5, 2021 2:01 UTC (Thu) by Ranguvar (subscriber, #56734) [Link] (8 responses)

Do you mind elaborating why this matters to yu?

I admit I never really saw the point of GVim compared to terminal vim.

New features in Neovim 0.5

Posted Aug 5, 2021 13:34 UTC (Thu) by jond (subscriber, #37669) [Link]

I used to use gvim from time to time. In my case I think it was that sometimes it was quite convenient to interact with the tool/menu bar. I moved exclusively to terminal some time prior to switching to neovim, so the lack of drop-in replacement for gvim hasn't bothered me personally.

New features in Neovim 0.5

Posted Aug 5, 2021 14:50 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

On the rare occasion I need to move a lot of text back and forth between other GUI programs, it's a lot easier when text selection and middle click DWIM. nvim gets the paste side correct, but whether it sets the X selection from a mouse drag movement is very hit or miss. Even console vim is more reliable in that regard.

New features in Neovim 0.5

Posted Aug 5, 2021 15:05 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

Hmm. When selecting text in vim for middle-click paste, I get all kinds of padding spaces and such mixed in with the copy that I have to fix on the other side (which, inevitably, is missing useful editing tools and is a manual process to fix). I've started getting into the habit of using visual selection and then `:w!xsel -i -p` to send it to the clipboard. Are you using `:set mouse` (I have it off in tmux as well as vim/neovim)?

New features in Neovim 0.5

Posted Aug 7, 2021 12:24 UTC (Sat) by mgedmin (subscriber, #34497) [Link]

There are multiple ways of using copy/paste with vim in the console. Either you let vim talk to your display server (:set mouse=a, plus vim needs to be built with X11 support and the clipboard feature), in which case MiddleMouse will paste from the selection register. This becomes more complicated if you use Vim remotely (over ssh, which would need ssh's X11 forwarding enabled), especially if you also use screen/tmux (when you reattach an older session, $DISPLAY value may be wrong).

The other way is you let the terminal handle the pasting (if you use :set mouse=a, for most terminal emulators you can override it by holding down shift when middle-clicking). Recent versions of Vim support xterm's bracketed paste, so the paste should gets detected and work fine. Older versions of Vim see a bunch of keypresses, so you need to go into insert mode before pasting, and disable things like autoindent -- for which there's a handy :set pastetoggle=..., so you can hit a key, paste, then hit the key again.

For copying, there's no equivalent to xterm's bracketed paste, so you either need to use the clipboard feature and yank into the "* register, or you need to hold down shift while selecting text (which is hard if you use vertical splits or if the lines are longer than the width of the window, or if you want to preserve tabs).

New features in Neovim 0.5

Posted Aug 5, 2021 21:25 UTC (Thu) by karkhaz (subscriber, #99844) [Link] (2 responses)

On some distros, the 'gvim' package also provides a vim binary that is compiled with more options than the more minimal vim package. So you can continue running terminal vim, but with more features.

For example, on Arch, the vim package does not depend on Xorg or Wayland, while the gvim package transitively does. This means that gvim's vim binary integrates with the system clipboard, while regular vim does not.

If your vim can't talk to the clipboard, you have to copy text by selecting it with the mouse and middle-clicking elsewhere, which is probably not what you want if you prefer using the terminal. With X11 support, you can copy the visual selection onto the clipboard with Ctrl-C, and paste from the system clipboard with Ctrl-D, as follows:

nnoremap <C-d> :set paste<Return>"+p:set nopaste<Return><Esc>a
inoremap <C-d> <Esc>:set paste<Return>"+p:set nopaste<Return>a
vnoremap <C-c> "+y<Esc>

You could even remap the usual yank and put commands to copy and paste to the system clipboard, though I personally like the vim clipboard be separate from the system one.

Of course, you don't need to install gvim for all this if you just want clipboard support; an alternative would be to just compile vim with the right flags, and then you don't need to drag in gtk3 and other various libraries.

New features in Neovim 0.5

Posted Aug 5, 2021 22:15 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

On Fedora, there is `vim-enhanced` which has these things enabled (though I haven't used them myself as I'm content with selecting and middle click pasting).

New features in Neovim 0.5

Posted Aug 6, 2021 3:18 UTC (Fri) by jamessan (subscriber, #12612) [Link]

On some distros, the 'gvim' package also provides a vim binary that is compiled with more options than the more minimal vim package. So you can continue running terminal vim, but with more features.
None of that is needed with Neovim, since all features are always built in.

New features in Neovim 0.5

Posted Aug 14, 2021 5:30 UTC (Sat) by Seirdy (guest, #137326) [Link]

One of the nice things about GVim was that it had surprisingly low typing latency, for users who like instantaneous feedback. One person I know went out of her way to tune her compositor to minimize input delay, and she exclusively used GVim.

New features in Neovim 0.5

Posted Aug 5, 2021 6:10 UTC (Thu) by ceplm (subscriber, #41334) [Link]

Nobody knows the future of VimL (how successful the next generation of VimL will be) and move towards Lua is clearly visible (programmers just seem to like it very much), but in case it is needed there are efforts like https://github.com/tjdevries/vim9jit ... perhaps we can workaround VimL completely.

New features in Neovim 0.5

Posted Aug 5, 2021 17:06 UTC (Thu) by krakensden (subscriber, #72039) [Link] (1 responses)

I am a little sad that all of the user interface bits are being offloaded to plugins- it would be nice to be able to say "nvim has this feature, this is how you use it" without devolving into a bunch of caveats and configuration.

CoC.vim is a great illustration of this- a giant choose your own adventure config is required, that kind of sucks, but since everyone customizes it there is no pressure to have a good default experience.

New features in Neovim 0.5

Posted Aug 17, 2021 10:02 UTC (Tue) by Hi-Angel (guest, #110915) [Link]

> I am a little sad that all of the user interface bits are being offloaded to plugins

I am not sure what makes you say that. The article doesn't say anything about functional being removed — on the contrary, it says neovim added some basic support for LSP-servers, that is a functional that was previously completely plugin-only.


Copyright © 2021, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds