| layout | title | category | permalink |
|---|---|---|---|
newsletter |
Neovim 0.10 |
newsletter |
/news/2024/05 |
Neovim is still the world's most-loved editor.
Here are some highlights from Neovim 2022 (Nvim 0.8) development.
- LSP documentation hover now uses Nvim's builtin markdown parsing to render markdown in docstrings.
- LSP client now has support for fswatch, to improve efficiency and performance of watching many files in a big workspace.
- inlay hint support: neovim/neovim@643546b
- leverages the new inline virtual text: neovim/neovim@efa9b29.
grepprgnow use ripgrep if available neovim/neovim@20b3867
- Neovim-branded colorscheme neovim/neovim@64a1402
- Built in commenting: neovim/neovim#28176
- osc52 clipboard neovim/neovim@748bc4d
- osc8: treesitter queries can annotate text as URLs, which Nvim will then emit to the host terminal wrapped in OSC 8. Supporting terminals will activate these tokens as hyperlinks.
- support Super and Meta keys feat(tui): support Super and Meta modifiers neovim/neovim#24357
Developing treesitter grammars is now as accessible as developing plugins.
With :InspectTree and :EditQuery you can start experimenting with the
treesitter parsing of any buffer (C, Lua, vimscript, vimdoc, markdown are builtin).
And these views are connected to the buffer: when you move your cursor in the
AST or the query, the relevant buffer text is highlighted, so you can instantly see how
changes in one affect the other.
vim.system(): neovim/neovim@c0952e6- Nvim ships with annotations for
vim.fn.xxx, so LSP servers like LuaLS can show docstrings and type information. neovim/neovim@42333ea vim.iter: neovim/neovim@ab1edecvim.snippetvim.keycode: neovim/neovim@7e70ca0- base64 module neovim/neovim@224f303
- LuaLS type checking, annotations
- Work by dundargoc, zeer
Automated generation of the online Nvim documentation was rewritten by replacing an old AWK script with Lua + tree-sitter. We can have nice things.
- massive improvements by lewis,
@inlinedoc, performance, ...
Compare the old layout (left) to the new one (right):
Nvim UIs are just (inverted) plugins. And nvim itself is a self-hosting UI: when you run nvim in a terminal, it starts the TUI as a nvim --embed child process.
Just like Nvim GUIs, you can connect the nvim TUI to any Nvim server to see its UI! You can try it right now:
- Start a server at address
./foo(creates afoofile in the current directory):nvim --listen ./foo - From a different terminal (in the same directory as
./foo), connectnvimto the server:nvim --remote-ui --server ./foo
Developing with the holistic system in mind. Thinking about long-term effects, composability of concepts and economy of interfaces.
examples of devs working to arrive at a long-term solution instead of short-term hacks:
v:completed_itemandCompleteChangedenhancements which avoided new concepts ("attach to completion provider") & surface area for LSP completion support.- diagnostic
goto_next(severity=nil)instead of special-caseseverity="auto". - echanovski reporting performance-based test failures, and rewriting
vim.deprecate()to be faster to remove subtle costs of our evolution strategy. - dundar help with test conventions and quality, which improves life for new and existing contributors.
- nvim_open_win() supports all kinds of windows instead of only floats. this was difficult and careful work that resulted in a much better interface.
upcoming:
- build.zig : our build system is in better shape than ever (it's fast, "just works" for users starting from zero, and maintainable). And having mastered cmake, yet we're exploring zig to replace it all. This is one of those relatively cheap side-quests that could yield extreme benefits (cross-compilation, reduced maintenance costs, avoidance of cmake baggage), or we could put it on ice for years or forever. Being able to probe these forbidden ideas is extremely powerful.
- utf8proc potentially improves our unicode support. the grapheme algorithm is much better. utf8proc contains all the data which now is in unicode_tables.generated.h internally.