[QUESTION] Nvim 0.8 support?

[edwintorok]

• I have searched open and closed issues for this question

Neovim 0.8 is out: https://github.com/neovim/neovim/releases/tag/v0.8.0
Fedora 37 beta already includes it.

The minimal set of updates so far to get it working (due to the API changes) seem to be:

diff --git a/lua/doom/modules/core/treesitter/init.lua b/lua/doom/modules/core/treesitter/init.lua
index c1c0e71..c90a2b2 100644
--- a/lua/doom/modules/core/treesitter/init.lua
+++ b/lua/doom/modules/core/treesitter/init.lua
@@ -42,13 +42,13 @@ treesitter.settings = {
 treesitter.packages = {
   ["nvim-treesitter"] = {
     "nvim-treesitter/nvim-treesitter",
-    commit = "d76b0de6536c2461f97cfeca0550f8cb89793935",
+    commit = "7ccb9a056fa43da243e3a439109c354c551c51b6",
     run = ":TSUpdate",
     branch = "master",
   },
   ["nvim-ts-context-commentstring"] = {
     "JoosepAlviste/nvim-ts-context-commentstring",
-    commit = "4befb8936f5cbec3b726300ab29edacb891e1a7b",
+    commit = "4d3a68c41a53add8804f471fcc49bb398fe8de08",
     after = "nvim-treesitter",
   },
   ["nvim-ts-autotag"] = {

diff --git a/lua/doom/modules/features/repl/init.lua b/lua/doom/modules/features/repl/init.lua
index 6c173bb..2248493 100644
--- a/lua/doom/modules/features/repl/init.lua
+++ b/lua/doom/modules/features/repl/init.lua
@@ -41,7 +41,7 @@ repl.settings = {
 repl.packages = {
   ["iron.nvim"] = {
     "hkupty/iron.nvim",
-    commit = "500aae3686b69dac3985e50dfaae074bcc2f2d94",
+    commit = "d1e80812aacd0c7e1a5c3050596716851d223ce9",
   },
 }
 
@@ -51,7 +51,7 @@ repl.configs = {
 
     local settings = vim.tbl_deep_extend("force", {}, doom.features.repl.settings)
     settings.config.repl_open_command =
-      require("iron.view").curry[settings.config.position](settings.config.size)
+      require("iron.view")[settings.config.position](settings.config.size)
 
     iron.setup(settings)
   end,

AFAICT nvim-treesitter still supports Neovim-0.7, and doom-nvim's requirement is already minimum 0.7, so it might be possible to update this and support both 0.7 and 0.8.
Not so sure about Iron.nvim will have to test.

Provided that it keeps working on Neovim-0.7 would you be interested in a PR that adds (experimental) support for Neovim-0.8?

[connorgmeehan]

Yep I would love that edwin, there are a number of changes I'd like to make to take advantage of 0.8 I just haven't had the time just yet. Is doom-nvim currently broken on 0.8? If so I could fix that tonight.

[edwintorok]

Completely broken on Nvim 0.8 yes:

Error detected while processing /home/edwin/.local/share/nvim/site/pack/packer/start/nvim-treesitter/plugin/nvim-treesitter.lu
a:
E5113: Error while calling lua chunk: .../start/nvim-treesitter/lua/nvim-treesitter/highlight.lua:14: attempt to index local '
hlmap' (a nil value)
stack traceback:
        .../start/nvim-treesitter/lua/nvim-treesitter/highlight.lua:14: in main chunk
        [C]: in function 'require'
        .../packer/start/nvim-treesitter/plugin/nvim-treesitter.lua:12: in main chunk

The diff above gets it to a point where it is able to start up, but some other plugins are still broken, e.g. editing a python file raises this quite a lot:

Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/lsp.lua:1513: attempt to call field 'is_closing' (a
 nil value)                                                                                                                   
stack traceback:                                                                                                              
        /usr/share/nvim/runtime/lua/vim/lsp.lua:1513: in function 'is_stopped'                                                
        /usr/share/nvim/runtime/lua/vim/lsp.lua:598: in function 'send_changes'                                               
        /usr/share/nvim/runtime/lua/vim/lsp.lua:655: in function ''                                                           
        vim/_editor.lua: in function <vim/_editor.lua:0>   

[edwintorok]

Would potentially need to find which plugins should be updated such that doom-nvim can keep working on both Nvim 0.7 and Nvim 0.8 (I do use Nvim 0.7 daily and will likely keep using it for a few years more, 0.8 is more experimental for now)

[connorgmeehan]

Yeah I was having a play around with updating all the plugin pinned commit shas, and I'm pretty sure plugin maintainers are going to start dropping 0.7 compatibility. I think the solution is going to be providing backwards compatible commit shas for each problem plugin. I'll use iron.nvim as an example as I know it's no longer backwards compatible with 0.7.

repl.packages = {
  ["iron.nvim"] = {
    "hkupty/iron.nvim",
    commit = {
      "0.7" = "<compat_commit_sha>",
      latest = "c5345e72ebdd84585eec6272755aa26233431317",
    }
  },
}

The part that I'm not looking forward too is adding version checks to the config schemes, i.e. repl, switching between deprecated .curry property.

    if vim.fn.has("0.7") then
      settings.config.repl_open_command =
        require("iron.view").curry[settings.config.position](settings.config.size)
    else
      settings.config.repl_open_command =
        require("iron.view")[settings.config.position](settings.config.size)
    end

[edwintorok]

I haven't tried (I have 0.8 "at home", and 0.7 "at work"), but wouldn't the latest iron.nvim be compatible with 0.7 still? (there are some 'backward compat' commits in its history and it doesn't explicitly say which version it wants).
Although I see your point eventually plugins will start dropping 0.7 support and if they introduce breaking changes after that then complexity in doom will grow.

[connorgmeehan]

I'm not 100% sure if they've dropped support but from previous nvim version changes plugin authors are pretty quick to drop support. But I agree, I really want to keep doom-nvim as dead simple as possible so adding all these backwards compatibility cases is not ideal. Another option would be adding a module.min_nvim_version = 0.8 field to each module so they can be excluded safely from execution.

[connorgmeehan]

Hey @edwintorok, I just released a new version of doom-nvim that adds support for 0.8 without breaking 0.7. You might need to run :DoomNuke all (new command, basically re-installs all packer dependencies on next launch) after upgrading neovim as packer can get stuck due to the breaking changes to treesitter.

[edwintorok]

Great, thanks a lot. The doomnuke is very useful, I had something like this in my dotfiles Makefile for a while:

rm -rf ~/.local/share/nvim/site/pack/packer/opt/* ~/.local/share/nvim/site/pack/packer/start/*
rm -f ~/.config/nvim/plugin/packer_compiled.lua ~/.cache/nvim/luacache* ~/.local/share/nvim/rplugin.nvim

Even with DoomNuke switching to latest version requires running PackerSync at least twice because the first one fails midway through, but I think that is to be expected on a major switch like from 0.7 to 0.8.