(mini.files) Stops working after editing workspace via LSP actions

[marcusandre]

Hello!

Foremost, thank you for all the great plugins, the time you are putting into mini.nvim and the outstanding support.

Introduction
I have one small observation in mini.files. To enable LSP features, I created a custom handler that applies file renames to the workspace to update imports in all files that are using code from the renamed file. This works great and is another great layer on top of mini.files.

My problem
Neovim will open all updated files in buffers in the background, while mini.files will remain opened. Most of the time, this works without any problems but sometimes, it prints me the following error:

Error executing vim.schedule lua callback: ...i5of/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1460: attempt to index a nil value

stack traceback:
        ...i5of/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1460: in function 'explorer_update_cursors'
        ...i5of/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:791: in function 'close'
        ...i5of/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1300: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

After that, I am not able to interact with mini.files any more. Trying to close it manually with lua MiniFiles.close() is also not having any effect.

I know this might be hard to verify for you, but I think it is somehow related to mini.files cursor of the buffers. I am currently using version 8e18eb9.

Thanks a lot!

---

My current implementation

-- Handler for `HandlerFilesActionRename`
M.file_on_rename = function(from, to)
  if vim.lsp.get_active_clients then
    local clients = vim.lsp.get_active_clients()

    for _, client in ipairs(clients) do
      if client.supports_method("workspace/willRenameFiles") then
        local resp = client.request_sync("workspace/willRenameFiles", {
          files = {
            {
              oldUri = vim.uri_from_fname(from),
              newUri = vim.uri_from_fname(to),
            },
          },
        }, 1000, 0)
        -- I think I could close mini.files here, but I prefer to leave it open to maybe do more operations
        if resp and resp.result ~= nil then vim.lsp.util.apply_workspace_edit(resp.result, client.offset_encoding) end
      end
    end
  end
end

-- Autocmd
vim.api.nvim_create_autocmd("User", {
  pattern = "MiniFilesActionRename",
  callback = function(event)      
    file_on_rename(event.data.from, event.data.to)
  end,
})

[echasnovski]

Nice dedication to creating something for yourself!

I am not really sure why this is happening. I've added this slightly refactored version inside the autocommand and could not reproduce this:

local file_on_rename = function(from, to)
  local ok, clients = pcall(vim.lsp.get_active_clients)
  if not ok or type(clients) ~= 'table' then return end

  clients = vim.tbl_filter(function(x) return x.supports_method('workspace/willRenameFiles') end, clients)

  for _, client in ipairs(clients) do
    local resp = client.request_sync(
      'workspace/willRenameFiles',
      { files = { { oldUri = vim.uri_from_fname(from), newUri = vim.uri_from_fname(to) } } },
      1000,
      0
    )

    -- I think I could close mini.files here, but I prefer to leave it open to maybe do more operations
    if resp and resp.result ~= nil then vim.lsp.util.apply_workspace_edit(resp.result, client.offset_encoding) end
  end
end

Although, I don't think there is an active proper LSP which utilizes "workspace/willRenameFiles" method.

Based on the i5of/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1300: in function '' line in log, this happens inside tracking for lost focus when it decided that the focus is lost. Meaning that some of the changes already lead to 'mini.files' not being current and thus starting closing.

There is an easy (and probably a worthwhile) fix to call that MiniFiles.close() with pcall (which will not propagate errors), but I am hesitant about adding it. Mostly because this will silence what might be useful errors (like this one).

---

Unfortunately, I can not help here without more details. For example:

• What are the exact steps leading to this happening? I understand that this is not happening reliably, but it makes helping not easy.
• What LSP servers are active when this error happens?

[marcusandre]

Thanks for the feedback and the refactoring. I learned a new thing! ♥️

What LSP servers are active when this error happens?

It happened while using tsserver. This server is definitely capable of workspace/willRenameFiles. It did not happen in other projects with other LSP servers I think. Or I was just lucky that everything went right.

What are the exact steps leading to this happening?

• I have some buffers open
• I open buffer one (it does not matter which one, but just as an example)
• I open mini.files rename a file and synchronise my changes
• LSP will be triggered, Neovim will open all files as buffers that have an import to the renamed file
• Neovim will print the mentioned error
• I can interact with all the buffers, do my changes as usual, but I cannot (manually) close or interact with mini.files any more

---

This is happening very sporadic. So, we can also close this Issue and if I have figured out more scenarios and I really see a problem with mini.files here, we could open that again. That would be fine with me, since it is very difficult to reproduce for you.

[echasnovski]

This is happening very sporadic. So, we can also close this Issue and if I have figured out more scenarios and I really see a problem with mini.files here, we could open that again. That would be fine with me, since it is very difficult to reproduce for you.

Yeah, without reliable way to reproduce this, it is hard to know what is going on.

I will move this to discussions instead of closing. Thanks for understanding!