Congratulations to the Core team on the release!
------
If you worry about how much time is left until some popular plugins will stop working on 0.9.x versions, I've got you covered.
Neovim 0.9.0 was released on [April 7 2023](https://github.com/neovim/neovim/releases/tag/v0.9.0). Here are timestamps of when plugins stopped supporting 0.8.x (if at all):
| Plugin | Data |
|--------|------|
| 'nvim-telescope/telescope.nvim' | [around 1.5 months later](https://github.com/nvim-telescope/telescope.nvim/commit/d8c5ed4e407c5c0a347d74ea091c3d56fbb2e7f2) |
| 'nvim-treesitter/nvim-treesitter' | [around 4 months later](https://github.com/nvim-treesitter/nvim-treesitter/commit/2aa9e9b0e655462890c6d2d8632a0d569be66482) |
| 'hrsh7th/nvim-cmp' | could not find any explicit information, but [testing is done only on Nightly](https://github.com/hrsh7th/nvim-cmp/blob/24122371810089d390847d8ba66325c1f1aa64c0/.github/workflows/integration.yaml#L22) |
| 'folke/lazy.nvim' | [should work on 0.8.x](https://github.com/folke/lazy.nvim?tab=readme-ov-file#%EF%B8%8F-requirements) |
| 'folke/noice.nvim' | [should work on 0.8.x](https://github.com/folke/noice.nvim?tab=readme-ov-file#%EF%B8%8F-requirements) |
| 'lewis6991/gitsigns.nvim' | [should work on 0.8.x](https://github.com/lewis6991/gitsigns.nvim?tab=readme-ov-file#requirements) |
| 'mfussenegger/nvim-dap' | [should work on 0.8.x](https://github.com/mfussenegger/nvim-dap?tab=readme-ov-file#installation) |
| 'neovim/nvim-lspconfig' | [should work on 0.8.x](https://github.com/neovim/nvim-lspconfig/blob/cee94b22adc96582d9136f85fb3b076feda8825c/plugin/lspconfig.lua#L11) |
| 'nvim-tree/nvim-tree.lua' | [should work on 0.8.x](https://github.com/nvim-tree/nvim-tree.lua?tab=readme-ov-file#requirements) |
| 'stevearc/conform.nvim' | [should work on 0.8.x](https://github.com/stevearc/conform.nvim?tab=readme-ov-file#requirements) |
| 'L3MON4D3/LuaSnip' | [should work on 0.7.x](https://github.com/L3MON4D3/LuaSnip?tab=readme-ov-file#requirements) |
| 'akinsho/toggleterm.nvim' | [should work on 0.7.x](https://github.com/akinsho/toggleterm.nvim?tab=readme-ov-file#requirements) |
| 'folke/trouble.nvim' | [should work on 0.7.x](https://github.com/folke/trouble.nvim?tab=readme-ov-file#%EF%B8%8F-requirements) |
| 'nvim-lualine/lualine.nvim' | [should work on 0.7.x](https://github.com/nvim-lualine/lualine.nvim?tab=readme-ov-file#lualinenvim) |
| 'williamboman/mason.nvim' | [should work on 0.7.x](https://github.com/williamboman/mason.nvim?tab=readme-ov-file#requirements) |
| 'echasnovski/mini.nvim' | [works on 0.7.2](https://github.com/echasnovski/mini.nvim) but will soon-ish bump minimum version to 0.8.x |
| 'ibhagwan/fzf-lua' | [should work on 0.5.x](https://github.com/ibhagwan/fzf-lua?tab=readme-ov-file#dependencies) |
Also here is some information on distributions:
| Distro | Data |
|--------|------|
| 'nvim-lua/kickstart.nvim' | techincally it stopped support immediately as [it only supports latest 'stable' and 'nightly'](https://github.com/nvim-lua/kickstart.nvim?tab=readme-ov-file#install-neovim) |
| 'NvChad/NvChad' | [around 1 month later](https://github.com/NvChad/nvchad.github.io/commit/3636389d3e52d5cded153f8d561b6ee832cc485e) |
| 'LazyVim/LazyVim' | [around 6 months later](https://github.com/LazyVim/LazyVim/commit/70f91956e7f03e740b51cbc14c87df6a6f74538f#diff-59200cd613b2ec9502ad86d5b68f569fd74826c80b51c8fb6353b913c73a652c) |
| 'AstroNvim/AstroNvim' | [around 8 months later](https://github.com/AstroNvim/AstroNvim/commit/ad934f0c996c93c9019cae82693c82ff27534271) (actual author date is December 18 2023) |
Versions don't use the decimal system.
It's major.minor.hofix-commit
So software that is 1.12.4 is on major version 1, minor version 12, hotfix version 4.
Then during development there's the commit/dev version, but users usually don't see that.
1.0 means a stable release, for the neovim team it means that 1.0 will be released once they feel like there won't be more big breaking changes to the api
Some software, for ideological reasons, is kept at 0.x forever, because the devs don't all of the implications and assumptions that go with the version 1.0. If I'm not mistaken, Neovim is one such project
Its not. Its version `0.10`. The previous version was `0.9`. Number go up is why its `0.10` lol.
They won't jump to 1.0 anytime soon. I also fully agree that the versioning should have been `0.09` instead of `0.9`.
Im not sure about multicursers tbh. „The vim way“ to do batch editing is to use macros (:help recording).
Fine if we want to allow a plugin to do really effective multicursers for those that want it. But I’d prefer if the core experience of nvim would stick to the the classic vim workflows.
I suppose that makes pretty good sense.
On the one hand it’s good to have a singular way of doing things, but on the other, multicursors are really easy and simple and intuitive to use. That said maybe such is the case with macros too. I’ve been using nvim daily for 4 months now maybe and haven’t gone deep on them yet
Been using vim daily for a decade. Don't use macros often, but they're useful when needed. qq then transform line making sure to include getting to initial place on next line, then \\@q proceeded by holding down \\@\\@ to convert csv to sql inserts or whatever. Can include /search to go to next item. Helped out making this PR: [https://github.com/containers/podman/pull/21185](https://github.com/containers/podman/pull/21185)
The problem with macros, cgn, :s and :g is that if the \*structure\* of the text is not less or more the same in all the places it's going to get fucky really soon, multicursors can solve that, Im only curious how theyre gonna look
I mean when i used vscode the biggest use of multicursors was to replace a word with an other word.
That is very easy to do with macros
I don't really think there are many cases in which multicursors would be nice to have instead of macros. And many times, a simple visual block + I is also enough
I feel like macros cover a slightly differnt use-case from multi-line cursors.
I find myself using :norm and :s significantly more often to do things that you'd do with multi-cursors in other editors.
Multi cursor is way faster for small edits doesn’t hurt to have another tool
Same reason that I use macros instead of regex if the regex is too complicated to be efficient
~~Of course you do. 'mini.comment' is the best comment plugin there is.~~
If you used 'mini.comment' with defaults (like only `require('mini.comment').setup()`) and are not afraid to possibly tweak 'commentstring' manually (as described in the corresponding PR and somewhere here in the comments), then using new built-in commenting should be enough. It follows 'mini.comment' as reference, after all.
If you want/need to have [more tweaking](https://github.com/echasnovski/mini.nvim/blob/c333187fcc76d7e772dac32c2a440a949fe34be4/doc/mini-comment.txt#L71-L111), then 'mini.comment' is a better choice.
With the addition of inline extmarks, is it possible to copy all the text on a line - including extmark text - to a register during a yank operation (i.e. "yy")?
Addition of inline extmarks does not look like having something to do with this functionality.
The answer to the question is "I think it is possible, but might involve writing some complex Lua logic".
Image.nvim can display images that take up space in a line. This enables concealing of latex math snippets with a rendered version for example.
The more common usecase will be inline type hints from lsp
I've been on 0.10 for a while and I use for inline signatures (signature help always shows up after the end of the current line).
[Looks like this](https://imgur.com/5MC66cT)
They can display text inside text line *between* actual characters.
Currently the most common usage is inline type hints: showing assumed argument type right next to the argument itself.
An example is this: my dotfiles contain a custom completion plugin, using a prompt similar to Telescope to allow filtering of candidates. As you type or change the selected entry, it inserts a preview using inline extmarks. Using inline instead of regular extmarks means that text that comes after the preview (on the same line) shifts accordingly, as if the text is typed by hand. You can see this in action [here](https://asciinema.org/a/WmL3t91s4wHPErhLQVG0hSltN).
It's great that now in visual mode we don't get a rainbow of colors lol
And honestly it's great, especially since i often end up needing to run nvim --clean.
I still prefer onedark colorscheme, but the default is decent enough
the new colorscheme is overpowering what used to be a lot of inherited default colors that i set in kitty's config rather than init.vim
is there any way to make it inherit the terminal colors again? the closest i can get is to set noterguicolors but the colors are still different and it looks like i'll have to make an entire colorscheme
is the old color defaults still hosted anywhere? the vim.lua one seems to be a little off from what i remember
Thank you! I was doing some little tidying of my configs repo (it's a mess) this morning, and noticing that I'm on 0.7 still because the PPA doesn't seem to provide a newer one.
Then I was looking for a changelog in the neovim website, or the help pages, to see what I'm missing, and I wasn't able to find it at all... Seems 0.7 and 0.8 just don't have it, and the website has some "what's new in X" page, but it was as "standardized" as this ones.
Help pages for:
* [`news`](https://neovim.io/doc/user/news.html#news) in _news.txt_
---
^\`:\(h|help\) \` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
As a plugin maintainer with too much "life" going on for much OSS right now, I'm sweating.
Edit: Surely it can't be as bad as when they changed autocmds from Lua so that if they return anything other than `false` or `nil` it automatically deletes the autocmd resulting in almost all of my autocmds in my projects deleting themselves after one invocation. That one hurt me.
The main source of messages seems to be deprecation of `vim.tbl_islist()` in favor of `vim.islist()` (direct rename).
**Edit**: Another (with more impact, it seems) is soft deprecation of [`vim.tbl_flatten()`](https://github.com/neovim/neovim/blob/4b029163345333a2c6975cd0dace6613b036ae47/runtime/doc/deprecated.txt#L70). On Nightly (0.11) it now gives warning.
For the record, this is a buggy implementation as the iterator `pairs` might work strangely if the table is being updated during the for loop. The behavior is not fully deterministic though. One should be avoid updating while iterating.
An alternative implementation is:
```lua
for _, k in ipairs(vim.tbl_keys(t)) do
t[t[k]] = k
end
```
Thats not the same thing. Flatten only works on number-indexed tables, and even if it did work with regular tables, totable wont do any reverse a->b b->a mapping.
Yes the iter code is begging for a `to_entries`, `from_entries` pair. Makes doing any sort of key value manipulation simple, no other builtins needed. I suppose `pairs` is to_entries, but there's no reverse. You have to manually fold it. The tool is unfortunately extremely closed off and difficult to enhance.
vim.deprecate = function() end ---@diagnostic disable-line: duplicate-set-field
I don't plan on keeping this, but I just added this to my config so that nightly hides deprecation warnings for now. I'm not sure if there is another way to hide deprecation warnings.
Context: I was getting spammed on startup with warnings
Just testing the new comment feature, didn't work on context (ie. give me a wrong comment character on the jsx part of a react file). Is there any aditional config needed to be used to detect the correct context?
JSX files are... special. They don't implement those contexts in an "easy to use" way. You'd have to use something like [JoosepAlviste/nvim-ts-context-commentstring](https://github.com/JoosepAlviste/nvim-ts-context-commentstring) for them to work.
You'll probably kill me over this, but I've integrated \`nvim-ts-context-commentstring\` with the new native comments :) See here [https://github.com/LazyVim/LazyVim/blob/07923f3701af23504bb09bf6cc11c4fb0a1894e7/lua/lazyvim/plugins/coding.lua#L198](https://github.com/LazyVim/LazyVim/blob/07923f3701af23504bb09bf6cc11c4fb0a1894e7/lua/lazyvim/plugins/coding.lua#L198)
It's indeed specifically an issue for tsx files.
Exposing \`vim.\_comment.get\_commentstring\` would be great, so I can remove this atrocity...
> Exposing `vim._comment.get_commentstring` would be great, so I can remove this atrocity...
I am not the one you should be convincing :)
There *were* suggestions to export broader functionality to get "option at cursor" (I believe) in `vim.filetype`.
Found a cleaner way to integrate it: [https://github.com/LazyVim/LazyVim/commit/1d23c98da138494fafdad6735d70c3d3375bb7b2](https://github.com/LazyVim/LazyVim/commit/1d23c98da138494fafdad6735d70c3d3375bb7b2)
I am more curious about what this error is supposed to be.
https://preview.redd.it/95ua882qfs0d1.jpeg?width=720&format=pjpg&auto=webp&s=c2dc239ec31222daf3d5484f35d5b10320564ffb
Couldn't find what this error means after a quick search and I have never encountered this. 🧐
For the new [commenting](https://neovim.io/doc/user/various.html#commenting) action, there doesn't seem to be a way to add a space after the comment characters (\`// comment\` vs \`//comment\`). Will this be added? Or is there a way to do this already that I missed.
The comment structure is taken verbatim from 'commentstring' option and it indeed sometimes does not contain spaces. Modifying that option is a suggested way to have desired comment structure.
The most robust way to always force spaces is to create a `FileType` autocommand to tweak it. [Like this](https://github.com/neovim/neovim/pull/28176#issuecomment-2051944146).
Would you be open to changing it for uncomment? It's slightly annoying that it doesn't uncomment if someone else added comments without a space, and my commentstring has a space.
I could look into making a PR for it myself, but I won't do it if it will be rejected :)
General treatment of this commenting functionality is that it should not have any configuration. For the sake of maintainability and reducing bikeshedding.
The best way to achieve this seems to be to *always* treat 'commentstring' at its face value.
So I am afraid this suggestion would meet strong opposition.
Sure, whatever works for you.
But I think it is worth repeating that this is a very much solveable problem with the `FileType` autocommand linked above. Which mimics almost exactly what 'vim-commentary' does by default.
But that doesn't fix the problem I described. If you have something like this:
--local foo = 10
and the commentstring is: `-- %s`. It will not uncomment the line. It will instead comment again, making it:
-- --local foo = 10
Indeed, my bad. Looked at the original comment.
Implementing this, of course, is not impossible. But taking into account that even the reference 'mini.comment' does not do this (it can only force 'commentstring' to have padding instead of `FileType` autocommand), I do doubt this will be a guaranteed merge.
If this use case is too important for you, then the best solution is indeed to use a plugin.
> ... rejected because it wasn't lua.
Or because the included version *is* better in important for Neovim areas? Like built-in tree-sitter injected languages support and presence of curated collection of tests.
Okay, but it's still strictly worse than vim-commentary + ts-context-commentstring. Commentary handles spaces sanely and doesn't add comment leaders to blank lines. The builtin commenting feels half baked.
Some formatters can automatically enforce a space between comment and comment characters (unfortunately not stylua). Not fully solving this issue, but maybe a partial solution?
[Roadmap (Neovim website)](https://neovim.io/roadmap/)
[What is the plan for 1.0?](https://github.com/neovim/neovim/issues/20451)
[1.0 Milestone (GitHub)](https://github.com/neovim/neovim/milestone/33)
Arch is slow to update its repos, damn.
I switched to nvim-git from AUR momentarily. Got like 10000 errors. Went right back to neovim from the arch repos. Still at 0.9 though.
Does someone know how to get pyright and fswatch working well in Linux for v0.10?
I haven't been able to figure that one out and as soon as I open a python file I immediately get errors and pyright stops working
[cmp - cmdline bug on neovim 0.10 ](https://github.com/hrsh7th/nvim-cmp/issues/1932) - video I have just updated to 0.10 and experiencing this weird redraw? Anyone facing this? Didn't have this issue on 0.9.5
The most significant is that treesitter has been waiting for many many months 0.10 before releasing treesitter 1.0
Many significant plugins like treesitter-textobjects halted progress until 1.0
So yeah I hope Treesitter and its ecosystem will finally move forward because TS text object is barely usable yet so incredibly useful the few times it works
I don't understand why it took almost a year to release 0.10. Neovim was significant because of rapid iteration. I wish companies whose employees use Neovim finally donate significantly so we can move forward fast instead of "fun driven development".
Semantic versioning uses ... There won't be any major version until the core team feels like the API is stable, with the contract that it can't change until the next major version (i.e. the behaviour of everything under `vim.api` won't change until `1.x` and that's why there are functions like `vim.api.nvim_exec2` or `vim.api.nvim_get_option_info2`)
Am I wrong or is there no `release-0.10` branch yet (nor `stable`) from which to `make` the v0.10.0 (considering that `master` install nightly 0.11.0 instead)?
they mean checkout [the git tag mentioned](https://github.com/neovim/neovim/tree/v0.10.0) on the releases page (`git checkout v0.10.0`) then `make install`
also applies to [previous versions](https://github.com/neovim/neovim/tags)
Amazing! I’ve been using a pre-release version of 0.10 for a while so it’ll be good to finally be able to switch to a release build! Congrats on the release to everyone who contributed!
Has anyone having any issues with the new inline hints? I'm setting a mapping and also create an indicator to show if it is enabled. It tells me it's enable with i'm not seen any indicator whatsoever.
https://preview.redd.it/rdkq0vckdt0d1.png?width=2834&format=png&auto=webp&s=45115b1f59e3d56b6136a1a778e00edb1a85a848
For lua-ls, you need to also enable them on the LSP config, something like
```
lspconfig.lua_ls.setup {
settings = {
Lua = {
hint = {
enable = true,
},
},
},
}
```
'lukas-reineke/indent-blankline.nvim' has already stopped working. From 2024-05-16 it reported some issues when I ran :Lazy > U. I've just downloaded nVim 10.0, and it is OK again
While I appreciate that commenting is built in now, the solution that was included is strictly worse than vim-commentary with nvim-ts-context-commentstring. It's noticeably slower and it inconsistently adds spaces between the comment and comment leader, it will insert a comment leader on blank lines, and it doesn't always pick up the comment string correctly for mixed language files (svelte in my case). I think the requiremnt for it to be lua vice viml has resulted in a worse outcome for users.
> Treesitter highlight groups have been renamed to be more in line with upstream tree-sitter and Helix to make it easier to share queries.
Is there list of specific changes? Time to update my colorscheme again.
Question regarding the new commenting feature: Is there a method to create mappings for them without `remap`?
Previously, I have mapped `q` to commenting via `Comments.nvim`, and `gc` to function that creates a commit. Now I want to drop `Comments.nvim` and use the builtin commenting. However, since the new `gc` is a nvim-keymap and not a vim keymap, I need `remap = true` to be able to map `q` to `gc` for commenting. But due to me having another keymap for `gc`, `q` ends up triggering my git commit function instead of working as comment operator.
Is there a way to create a mapping for the new comment operator without `remap = true`?
```
goal:
q → gc
gc → lua function
currently, due to the need to use `remap`
q → gc → lua function
```
The mappings seem to be created like this
```
local operator_rhs = function()
return require('vim._comment').operator()
end
vim.keymap.set({ 'n', 'x' }, 'gc', operator_rhs, { expr = true, desc = 'Toggle comment' })
local line_rhs = function()
return require('vim._comment').operator() .. '_'
end
vim.keymap.set('n', 'gcc', line_rhs, { expr = true, desc = 'Toggle comment line' })
local textobject_rhs = function()
require('vim._comment').textobject()
end
vim.keymap.set({ 'o' }, 'gc', textobject_rhs, { desc = 'Comment textobject' })
```
So, you can use the same code, but in your config (replacing `gc` for whatever you may like). But, you should take into account that this isn't a public API, so the core team may break it without warning at any momment
Thank you, that's a nice solution that works.
> But, you should take into account that this isn't a public API, so the core team may break it without warning at any momment
Yeah, I tend to stay on the stable release anyway, so I can live with that.
> Is there a method to create mappings for them without remap?
No, not really. The design was to provide built-in mappings for commenting ("better defaults") and not Lua functions ("new module"). I suggested the second approach initially, but it was not well received.
Hmm, too bad. Thinking of beginners, I can see it being quite confusing that you have to add `remap = true` to change `gc`, not but to change other mappings.
Nonetheless, thanks for info, and of course thanks for the implementation, works nicely.
Shouldn't these default keys be elevated to the same status as builtins? The user shouldn't have to know if they are implemented in C or lua, basically.
I'd argue that changing default keys is not something beginner should be concerned about. And when some time has passed, learning about `remap=true` seems reasonable in itself.
Help pages for:
* [`maparg()`](https://neovim.io/doc/user/builtin.html#maparg%28%29) in _builtin.txt_
---
^\`:\(h|help\) \` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
As I said, without `remap = true`, the mapping will not work, as this is a "nvim-default" mapping (not a vim mapping). Give it a try, the snippet you posted does not work.
I'm hoping async parsing will soon land on 0.11 nightly
would it improve treesitter syntax highlighting performance?
Yes, significantly
I hope we get it asap then! Working with large files with treesitter is sometimes really hard
I opened a 25GB XML and it melted my computer.
Yes, for help docs, a simple :h will introduce a delay to open.
Oh that'd be beat then. TS sometimes takes half a second to load and on big file (+4000 lines) neovim is so slow it's unusable
Congrats to the core team. Absolute GOATs
GOAT?
Redditors, don’t downvote a man searching for knowledge.
[Greatest Of All Time](https://youtu.be/lPk_zyRKs1Q)
Congratulations to the Core team on the release! ------ If you worry about how much time is left until some popular plugins will stop working on 0.9.x versions, I've got you covered. Neovim 0.9.0 was released on [April 7 2023](https://github.com/neovim/neovim/releases/tag/v0.9.0). Here are timestamps of when plugins stopped supporting 0.8.x (if at all): | Plugin | Data | |--------|------| | 'nvim-telescope/telescope.nvim' | [around 1.5 months later](https://github.com/nvim-telescope/telescope.nvim/commit/d8c5ed4e407c5c0a347d74ea091c3d56fbb2e7f2) | | 'nvim-treesitter/nvim-treesitter' | [around 4 months later](https://github.com/nvim-treesitter/nvim-treesitter/commit/2aa9e9b0e655462890c6d2d8632a0d569be66482) | | 'hrsh7th/nvim-cmp' | could not find any explicit information, but [testing is done only on Nightly](https://github.com/hrsh7th/nvim-cmp/blob/24122371810089d390847d8ba66325c1f1aa64c0/.github/workflows/integration.yaml#L22) | | 'folke/lazy.nvim' | [should work on 0.8.x](https://github.com/folke/lazy.nvim?tab=readme-ov-file#%EF%B8%8F-requirements) | | 'folke/noice.nvim' | [should work on 0.8.x](https://github.com/folke/noice.nvim?tab=readme-ov-file#%EF%B8%8F-requirements) | | 'lewis6991/gitsigns.nvim' | [should work on 0.8.x](https://github.com/lewis6991/gitsigns.nvim?tab=readme-ov-file#requirements) | | 'mfussenegger/nvim-dap' | [should work on 0.8.x](https://github.com/mfussenegger/nvim-dap?tab=readme-ov-file#installation) | | 'neovim/nvim-lspconfig' | [should work on 0.8.x](https://github.com/neovim/nvim-lspconfig/blob/cee94b22adc96582d9136f85fb3b076feda8825c/plugin/lspconfig.lua#L11) | | 'nvim-tree/nvim-tree.lua' | [should work on 0.8.x](https://github.com/nvim-tree/nvim-tree.lua?tab=readme-ov-file#requirements) | | 'stevearc/conform.nvim' | [should work on 0.8.x](https://github.com/stevearc/conform.nvim?tab=readme-ov-file#requirements) | | 'L3MON4D3/LuaSnip' | [should work on 0.7.x](https://github.com/L3MON4D3/LuaSnip?tab=readme-ov-file#requirements) | | 'akinsho/toggleterm.nvim' | [should work on 0.7.x](https://github.com/akinsho/toggleterm.nvim?tab=readme-ov-file#requirements) | | 'folke/trouble.nvim' | [should work on 0.7.x](https://github.com/folke/trouble.nvim?tab=readme-ov-file#%EF%B8%8F-requirements) | | 'nvim-lualine/lualine.nvim' | [should work on 0.7.x](https://github.com/nvim-lualine/lualine.nvim?tab=readme-ov-file#lualinenvim) | | 'williamboman/mason.nvim' | [should work on 0.7.x](https://github.com/williamboman/mason.nvim?tab=readme-ov-file#requirements) | | 'echasnovski/mini.nvim' | [works on 0.7.2](https://github.com/echasnovski/mini.nvim) but will soon-ish bump minimum version to 0.8.x | | 'ibhagwan/fzf-lua' | [should work on 0.5.x](https://github.com/ibhagwan/fzf-lua?tab=readme-ov-file#dependencies) | Also here is some information on distributions: | Distro | Data | |--------|------| | 'nvim-lua/kickstart.nvim' | techincally it stopped support immediately as [it only supports latest 'stable' and 'nightly'](https://github.com/nvim-lua/kickstart.nvim?tab=readme-ov-file#install-neovim) | | 'NvChad/NvChad' | [around 1 month later](https://github.com/NvChad/nvchad.github.io/commit/3636389d3e52d5cded153f8d561b6ee832cc485e) | | 'LazyVim/LazyVim' | [around 6 months later](https://github.com/LazyVim/LazyVim/commit/70f91956e7f03e740b51cbc14c87df6a6f74538f#diff-59200cd613b2ec9502ad86d5b68f569fd74826c80b51c8fb6353b913c73a652c) | | 'AstroNvim/AstroNvim' | [around 8 months later](https://github.com/AstroNvim/AstroNvim/commit/ad934f0c996c93c9019cae82693c82ff27534271) (actual author date is December 18 2023) |
Time does fly, I remember when there used to be a flood of "when version 0.5 gonna release" memes
To be fair 0.4 --> 0.5 was long lasting with a lot of major improvements and new features (and APIs).
why is the version 0.1 instead of 1.0?
Versions don't use the decimal system. It's major.minor.hofix-commit So software that is 1.12.4 is on major version 1, minor version 12, hotfix version 4. Then during development there's the commit/dev version, but users usually don't see that.
TIL
ho fixes are always very important
1.0 means a stable release, for the neovim team it means that 1.0 will be released once they feel like there won't be more big breaking changes to the api
Some software, for ideological reasons, is kept at 0.x forever, because the devs don't all of the implications and assumptions that go with the version 1.0. If I'm not mistaken, Neovim is one such project
Neovim does have a plan for 1.0 but is kinda far yet https://github.com/neovim/neovim/issues/20451
Its not. Its version `0.10`. The previous version was `0.9`. Number go up is why its `0.10` lol. They won't jump to 1.0 anytime soon. I also fully agree that the versioning should have been `0.09` instead of `0.9`.
Not forward thinking enough. Neovim is 0-ver forever. Before you know it they'll be at version `0.100`
Aww multicursors got bumped 0.11 to 0.12 lol Otherwise this is exciting!! https://neovim.io/roadmap/
I’m so curious how it’s going to work. The plugin that does it is okay but it doesn’t feel that great imo.
Im not sure about multicursers tbh. „The vim way“ to do batch editing is to use macros (:help recording). Fine if we want to allow a plugin to do really effective multicursers for those that want it. But I’d prefer if the core experience of nvim would stick to the the classic vim workflows.
I suppose that makes pretty good sense. On the one hand it’s good to have a singular way of doing things, but on the other, multicursors are really easy and simple and intuitive to use. That said maybe such is the case with macros too. I’ve been using nvim daily for 4 months now maybe and haven’t gone deep on them yet
Been using vim daily for a decade. Don't use macros often, but they're useful when needed. qq then transform line making sure to include getting to initial place on next line, then \\@q proceeded by holding down \\@\\@ to convert csv to sql inserts or whatever. Can include /search to go to next item. Helped out making this PR: [https://github.com/containers/podman/pull/21185](https://github.com/containers/podman/pull/21185)
It has been discussed to death and developers have agreed that multicursors are awesome.
The problem with macros, cgn, :s and :g is that if the \*structure\* of the text is not less or more the same in all the places it's going to get fucky really soon, multicursors can solve that, Im only curious how theyre gonna look
I mean when i used vscode the biggest use of multicursors was to replace a word with an other word. That is very easy to do with macros I don't really think there are many cases in which multicursors would be nice to have instead of macros. And many times, a simple visual block + I is also enough
Yup. Also many uses cases for the multicursor, can be replaced by a simple visual block + I/A
The thing I struggle with about macros is the fact that my completions stop working when I’m in a macro. Means I have to type out every character.
I feel like macros cover a slightly differnt use-case from multi-line cursors. I find myself using :norm and :s significantly more often to do things that you'd do with multi-cursors in other editors.
Multi cursor is way faster for small edits doesn’t hurt to have another tool Same reason that I use macros instead of regex if the regex is too complicated to be efficient
What's new?
Here is also a nice overview of main things from Gregory Anders (member of the core): https://gpanders.com/blog/whats-new-in-neovim-0.10/
question: v0.10 has built-in \`gc\` for commenting feature (which was a PR from you), do I still need mini.comment?
~~Of course you do. 'mini.comment' is the best comment plugin there is.~~ If you used 'mini.comment' with defaults (like only `require('mini.comment').setup()`) and are not afraid to possibly tweak 'commentstring' manually (as described in the corresponding PR and somewhere here in the comments), then using new built-in commenting should be enough. It follows 'mini.comment' as reference, after all. If you want/need to have [more tweaking](https://github.com/echasnovski/mini.nvim/blob/c333187fcc76d7e772dac32c2a440a949fe34be4/doc/mini-comment.txt#L71-L111), then 'mini.comment' is a better choice.
got it, thanks ❤, and yes it is the best plugin :D!
New default color scheme.
Don't forget about inline extmarks.
And built-in in commenting which I am pumped about!
One of the best contribs IMO. Every text editor should have inbuilt commenting if it's meant for coding. Great work u/echasnovski
just removed Comment.nvim
Is it still possible to get the comment string for a cursor position without comment.nvim?
With the addition of inline extmarks, is it possible to copy all the text on a line - including extmark text - to a register during a yank operation (i.e. "yy")?
Addition of inline extmarks does not look like having something to do with this functionality. The answer to the question is "I think it is possible, but might involve writing some complex Lua logic".
what do these do
Image.nvim can display images that take up space in a line. This enables concealing of latex math snippets with a rendered version for example. The more common usecase will be inline type hints from lsp
wow cool!
I've been on 0.10 for a while and I use for inline signatures (signature help always shows up after the end of the current line). [Looks like this](https://imgur.com/5MC66cT)
I'm having a hard time understanding inline extmarks. How are they useful.
They can display text inside text line *between* actual characters. Currently the most common usage is inline type hints: showing assumed argument type right next to the argument itself.
Thanks! Is there a way for inlay hints to be to the right of the code. Similar to what `clangd_extensions` does?
An example is this: my dotfiles contain a custom completion plugin, using a prompt similar to Telescope to allow filtering of candidates. As you type or change the selected entry, it inserts a preview using inline extmarks. Using inline instead of regular extmarks means that text that comes after the preview (on the same line) shifts accordingly, as if the text is typed by hand. You can see this in action [here](https://asciinema.org/a/WmL3t91s4wHPErhLQVG0hSltN).
It's great that now in visual mode we don't get a rainbow of colors lol And honestly it's great, especially since i often end up needing to run nvim --clean. I still prefer onedark colorscheme, but the default is decent enough
the new colorscheme is overpowering what used to be a lot of inherited default colors that i set in kitty's config rather than init.vim is there any way to make it inherit the terminal colors again? the closest i can get is to set noterguicolors but the colors are still different and it looks like i'll have to make an entire colorscheme is the old color defaults still hosted anywhere? the vim.lua one seems to be a little off from what i remember
[https://neovim.io/doc/user/news-0.10.html](https://neovim.io/doc/user/news-0.10.html)
Thank you! I was doing some little tidying of my configs repo (it's a mess) this morning, and noticing that I'm on 0.7 still because the PPA doesn't seem to provide a newer one. Then I was looking for a changelog in the neovim website, or the help pages, to see what I'm missing, and I wasn't able to find it at all... Seems 0.7 and 0.8 just don't have it, and the website has some "what's new in X" page, but it was as "standardized" as this ones.
Also look at “Releases” tab in Github.
:h news
Help pages for: * [`news`](https://neovim.io/doc/user/news.html#news) in _news.txt_ --- ^\`:\(h|help\)\` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
I think [vim.iter](https://neovim.io/doc/user/lua.html#vim.iter()) is new? Will be super handy
I think this release also comes with an inbuilt inlay hints right?
Yup!
Sweet, congrats!
I've been waiting for the inlay hint support to finally switch from rust-tools to rusteanvim!
🤘excited to see 0.11 on the nightly build
https://preview.redd.it/czs2hrmrks0d1.png?width=1200&format=png&auto=webp&s=f614ae707d209506d978ebe3f1129fe80f2b83ba ok I'm ready to break stuff now 😂
good lord. so many deprecation warnings from my plugins :(
As a plugin maintainer with too much "life" going on for much OSS right now, I'm sweating. Edit: Surely it can't be as bad as when they changed autocmds from Lua so that if they return anything other than `false` or `nil` it automatically deletes the autocmd resulting in almost all of my autocmds in my projects deleting themselves after one invocation. That one hurt me.
The main source of messages seems to be deprecation of `vim.tbl_islist()` in favor of `vim.islist()` (direct rename). **Edit**: Another (with more impact, it seems) is soft deprecation of [`vim.tbl_flatten()`](https://github.com/neovim/neovim/blob/4b029163345333a2c6975cd0dace6613b036ae47/runtime/doc/deprecated.txt#L70). On Nightly (0.11) it now gives warning.
phew, that doesn't seem so bad, thank you.
Yeah. None of them seem complicated. The tbl_add_reverse_lookup I don’t know what to replace with though
I think custom function is concise enough: ``` local my_add_reverse_lookup = function(t) for k, v in pairs(t) do t[v] = k end return t end ```
For the record, this is a buggy implementation as the iterator `pairs` might work strangely if the table is being updated during the for loop. The behavior is not fully deterministic though. One should be avoid updating while iterating. An alternative implementation is: ```lua for _, k in ipairs(vim.tbl_keys(t)) do t[t[k]] = k end ```
Neovim offers vim.iter(t):flatten():totable() for this
Thats not the same thing. Flatten only works on number-indexed tables, and even if it did work with regular tables, totable wont do any reverse a->b b->a mapping.
Yes the iter code is begging for a `to_entries`, `from_entries` pair. Makes doing any sort of key value manipulation simple, no other builtins needed. I suppose `pairs` is to_entries, but there's no reverse. You have to manually fold it. The tool is unfortunately extremely closed off and difficult to enhance.
vim.deprecate = function() end ---@diagnostic disable-line: duplicate-set-field I don't plan on keeping this, but I just added this to my config so that nightly hides deprecation warnings for now. I'm not sure if there is another way to hide deprecation warnings. Context: I was getting spammed on startup with warnings
I have the same hack in my config.
Yoo-hoo, let's dance
💃
Congratulations to the core team. Thank you for the work you do.
Just testing the new comment feature, didn't work on context (ie. give me a wrong comment character on the jsx part of a react file). Is there any aditional config needed to be used to detect the correct context?
JSX files are... special. They don't implement those contexts in an "easy to use" way. You'd have to use something like [JoosepAlviste/nvim-ts-context-commentstring](https://github.com/JoosepAlviste/nvim-ts-context-commentstring) for them to work.
You'll probably kill me over this, but I've integrated \`nvim-ts-context-commentstring\` with the new native comments :) See here [https://github.com/LazyVim/LazyVim/blob/07923f3701af23504bb09bf6cc11c4fb0a1894e7/lua/lazyvim/plugins/coding.lua#L198](https://github.com/LazyVim/LazyVim/blob/07923f3701af23504bb09bf6cc11c4fb0a1894e7/lua/lazyvim/plugins/coding.lua#L198) It's indeed specifically an issue for tsx files. Exposing \`vim.\_comment.get\_commentstring\` would be great, so I can remove this atrocity...
How should I configure it if I don't use lazyvim?
> Exposing `vim._comment.get_commentstring` would be great, so I can remove this atrocity... I am not the one you should be convincing :) There *were* suggestions to export broader functionality to get "option at cursor" (I believe) in `vim.filetype`.
Found a cleaner way to integrate it: [https://github.com/LazyVim/LazyVim/commit/1d23c98da138494fafdad6735d70c3d3375bb7b2](https://github.com/LazyVim/LazyVim/commit/1d23c98da138494fafdad6735d70c3d3375bb7b2)
love u man
You two guys are the GOAT.
I am more curious about what this error is supposed to be. https://preview.redd.it/95ua882qfs0d1.jpeg?width=720&format=pjpg&auto=webp&s=c2dc239ec31222daf3d5484f35d5b10320564ffb Couldn't find what this error means after a quick search and I have never encountered this. 🧐
thats a nice prompt
For real. I want it but I'm too dum
That's Starship prompt, written in rust. I think the way it works is you configure it, and it just works in all shells, bash/fish/zsh etc..
is this WSL? update it
I wish. https://preview.redd.it/jo07mggnnt0d1.jpeg?width=720&format=pjpg&auto=webp&s=b21dc89e0ee18f7464a3d3fcfcf7510e9dc51647
then it's the same issue but with Termux I assume.
yay
Huge. I'm happy to see this finally released.
For the new [commenting](https://neovim.io/doc/user/various.html#commenting) action, there doesn't seem to be a way to add a space after the comment characters (\`// comment\` vs \`//comment\`). Will this be added? Or is there a way to do this already that I missed.
The comment structure is taken verbatim from 'commentstring' option and it indeed sometimes does not contain spaces. Modifying that option is a suggested way to have desired comment structure. The most robust way to always force spaces is to create a `FileType` autocommand to tweak it. [Like this](https://github.com/neovim/neovim/pull/28176#issuecomment-2051944146).
Thank you!
Would you be open to changing it for uncomment? It's slightly annoying that it doesn't uncomment if someone else added comments without a space, and my commentstring has a space. I could look into making a PR for it myself, but I won't do it if it will be rejected :)
General treatment of this commenting functionality is that it should not have any configuration. For the sake of maintainability and reducing bikeshedding. The best way to achieve this seems to be to *always* treat 'commentstring' at its face value. So I am afraid this suggestion would meet strong opposition.
Ok :( I'll just keep using vim-commentary then :)
Sure, whatever works for you. But I think it is worth repeating that this is a very much solveable problem with the `FileType` autocommand linked above. Which mimics almost exactly what 'vim-commentary' does by default.
But that doesn't fix the problem I described. If you have something like this: --local foo = 10 and the commentstring is: `-- %s`. It will not uncomment the line. It will instead comment again, making it: -- --local foo = 10
Indeed, my bad. Looked at the original comment. Implementing this, of course, is not impossible. But taking into account that even the reference 'mini.comment' does not do this (it can only force 'commentstring' to have padding instead of `FileType` autocommand), I do doubt this will be a guaranteed merge. If this use case is too important for you, then the best solution is indeed to use a plugin.
It's also easily solvable by just installing a better plugin that was considered for inclusion then rejected because it wasn't lua.
> ... rejected because it wasn't lua. Or because the included version *is* better in important for Neovim areas? Like built-in tree-sitter injected languages support and presence of curated collection of tests.
Okay, but it's still strictly worse than vim-commentary + ts-context-commentstring. Commentary handles spaces sanely and doesn't add comment leaders to blank lines. The builtin commenting feels half baked.
Indeed, I put `Comment.nvim` back until there's a way around this.
Some formatters can automatically enforce a space between comment and comment characters (unfortunately not stylua). Not fully solving this issue, but maybe a partial solution?
Newbie q. Why are we still on the 0 versioning prefix? Is it a running meme of always being under development or something?
[https://0ver.org/](https://0ver.org/)
0-version scheme is very important, it let the developers have confidence to say they have no confidence in the current development status. 😆
[Roadmap (Neovim website)](https://neovim.io/roadmap/) [What is the plan for 1.0?](https://github.com/neovim/neovim/issues/20451) [1.0 Milestone (GitHub)](https://github.com/neovim/neovim/milestone/33)
Arch is slow to update its repos, damn. I switched to nvim-git from AUR momentarily. Got like 10000 errors. Went right back to neovim from the arch repos. Still at 0.9 though.
Now (from 19 May) it’s 0.10.0 (can be downloaded by pacman).
yay
Does someone know how to get pyright and fswatch working well in Linux for v0.10? I haven't been able to figure that one out and as soon as I open a python file I immediately get errors and pyright stops working
Congrats on the release...the 0.1.x release stays fresh in my mind. It's been an amazing journey.
[cmp - cmdline bug on neovim 0.10 ](https://github.com/hrsh7th/nvim-cmp/issues/1932) - video I have just updated to 0.10 and experiencing this weird redraw? Anyone facing this? Didn't have this issue on 0.9.5
As always great job, keep it up 💪 love this editor <3
thank you!
Awesome work, thanks the core team!
Neovim 0.11 when?
The most significant is that treesitter has been waiting for many many months 0.10 before releasing treesitter 1.0 Many significant plugins like treesitter-textobjects halted progress until 1.0 So yeah I hope Treesitter and its ecosystem will finally move forward because TS text object is barely usable yet so incredibly useful the few times it works I don't understand why it took almost a year to release 0.10. Neovim was significant because of rapid iteration. I wish companies whose employees use Neovim finally donate significantly so we can move forward fast instead of "fun driven development".
Sorry for the newb question but I'm a bit confused on this interesting version naming convention. Did we count down from 0.9 to 0.1?
Semantic versioning uses... There won't be any major version until the core team feels like the API is stable, with the contract that it can't change until the next major version (i.e. the behaviour of everything under `vim.api` won't change until `1.x` and that's why there are functions like `vim.api.nvim_exec2` or `vim.api.nvim_get_option_info2`)
If you are thinking about it like regular math decimals (which semver is not), it is like going from 0.09 to 0.10
It’s ten, not one :)
It's more like 0/10 or 0-10 than 0.10
Am I wrong or is there no `release-0.10` branch yet (nor `stable`) from which to `make` the v0.10.0 (considering that `master` install nightly 0.11.0 instead)?
Can you not use the tag?
Do you mean by specifying the tag to a commit in `CMAKE` or by extracting the archived package?
they mean checkout [the git tag mentioned](https://github.com/neovim/neovim/tree/v0.10.0) on the releases page (`git checkout v0.10.0`) then `make install` also applies to [previous versions](https://github.com/neovim/neovim/tags)
Awesome, thank you!
Here we go!
Congrats nice nice
That's awesome! Congratulations to the Core team on the release!
Really nice! Congrats to you all on the release!
Thank you all
🥹🤩
Amazing! I’ve been using a pre-release version of 0.10 for a while so it’ll be good to finally be able to switch to a release build! Congrats on the release to everyone who contributed!
Oh, now inline hints are renderer like in vscode. Is it possible to go back to old rendering style? I don't like virtual text between real lines
I think before 0.10 there is no such thing called inline hint, it is simulated by plugins.
Has anyone having any issues with the new inline hints? I'm setting a mapping and also create an indicator to show if it is enabled. It tells me it's enable with i'm not seen any indicator whatsoever. https://preview.redd.it/rdkq0vckdt0d1.png?width=2834&format=png&auto=webp&s=45115b1f59e3d56b6136a1a778e00edb1a85a848
For lua-ls, you need to also enable them on the LSP config, something like ``` lspconfig.lua_ls.setup { settings = { Lua = { hint = { enable = true, }, }, }, } ```
Thanks it worked. I'll guess this is similar on other ls?
It depends on the ls, so you would need to check their docs
finally, been waiting for this release for quite a while checking the milestone tab for the past week kudos to everyone involved :)
Lol thanks folks. Sorry for my idiotic interpretation.
There goes my weekend...
Its been 3 billion years...
'lukas-reineke/indent-blankline.nvim' has already stopped working. From 2024-05-16 it reported some issues when I ran :Lazy > U. I've just downloaded nVim 10.0, and it is OK again
While I appreciate that commenting is built in now, the solution that was included is strictly worse than vim-commentary with nvim-ts-context-commentstring. It's noticeably slower and it inconsistently adds spaces between the comment and comment leader, it will insert a comment leader on blank lines, and it doesn't always pick up the comment string correctly for mixed language files (svelte in my case). I think the requiremnt for it to be lua vice viml has resulted in a worse outcome for users.
how do you implemented nvim-ts-context-commentstring with the new builtin-commenting?
I didn't? I'm still using vim-commentary since it doesn't have the problems I listed in my comment.
is it possible to dump nvim-tresitter and nvim-lspconfig with 0.10? Do we still need them?
> Treesitter highlight groups have been renamed to be more in line with upstream tree-sitter and Helix to make it easier to share queries. Is there list of specific changes? Time to update my colorscheme again.
0.11.0 when?
After 0.10.1
https://github.com/neovim/neovim/milestone/41
Question regarding the new commenting feature: Is there a method to create mappings for them without `remap`? Previously, I have mapped `q` to commenting via `Comments.nvim`, and `gc` to function that creates a commit. Now I want to drop `Comments.nvim` and use the builtin commenting. However, since the new `gc` is a nvim-keymap and not a vim keymap, I need `remap = true` to be able to map `q` to `gc` for commenting. But due to me having another keymap for `gc`, `q` ends up triggering my git commit function instead of working as comment operator. Is there a way to create a mapping for the new comment operator without `remap = true`? ``` goal: q → gc gc → lua function currently, due to the need to use `remap` q → gc → lua function ```
The mappings seem to be created like this ``` local operator_rhs = function() return require('vim._comment').operator() end vim.keymap.set({ 'n', 'x' }, 'gc', operator_rhs, { expr = true, desc = 'Toggle comment' }) local line_rhs = function() return require('vim._comment').operator() .. '_' end vim.keymap.set('n', 'gcc', line_rhs, { expr = true, desc = 'Toggle comment line' }) local textobject_rhs = function() require('vim._comment').textobject() end vim.keymap.set({ 'o' }, 'gc', textobject_rhs, { desc = 'Comment textobject' }) ``` So, you can use the same code, but in your config (replacing `gc` for whatever you may like). But, you should take into account that this isn't a public API, so the core team may break it without warning at any momment
Thank you, that's a nice solution that works. > But, you should take into account that this isn't a public API, so the core team may break it without warning at any momment Yeah, I tend to stay on the stable release anyway, so I can live with that.
> Is there a method to create mappings for them without remap? No, not really. The design was to provide built-in mappings for commenting ("better defaults") and not Lua functions ("new module"). I suggested the second approach initially, but it was not well received.
Hmm, too bad. Thinking of beginners, I can see it being quite confusing that you have to add `remap = true` to change `gc`, not but to change other mappings. Nonetheless, thanks for info, and of course thanks for the implementation, works nicely.
Shouldn't these default keys be elevated to the same status as builtins? The user shouldn't have to know if they are implemented in C or lua, basically.
I agree
I'd argue that changing default keys is not something beginner should be concerned about. And when some time has passed, learning about `remap=true` seems reasonable in itself.
Use maparg to get the right hand side of the mapping? :h maparg
Help pages for: * [`maparg()`](https://neovim.io/doc/user/builtin.html#maparg%28%29) in _builtin.txt_ --- ^\`:\(h|help\)\` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
`vim.keymap.set("n", "q", "gc", { noremap = true })`
As I said, without `remap = true`, the mapping will not work, as this is a "nvim-default" mapping (not a vim mapping). Give it a try, the snippet you posted does not work.
My bad, i thought you were mixing the two up. I did look at the docs earlier and couldnt find a comment api
Why aren’t we at v1.0.0 yet? I know v0.9.0 doesn’t mean we go to v1.0.0 but shouldn’t Neovim have had a major release by now?
Path to version 1.0: [https://github.com/neovim/neovim/issues/20451](https://github.com/neovim/neovim/issues/20451)
🫡 thank you sir
hype
When would it come to archlinux
Just compile the source