Error when closing mini.files buffer with "ZZ"

[Anthony-Fiddes]

Contributing guidelines

• [X] I have read CONTRIBUTING.md
• [X] I have read CODE_OF_CONDUCT.md
• [X] I have updated 'mini.nvim' to latest version

Module(s)

mini.files

Description

Closing the mini.files buffer with the ZZ command causes weird errors to occur.

Neovim version

0.9.1

Steps to reproduce

1. Add minimal.lua to a folder.
2. Run nvim -nu minimal.lua .
3. Add a subfolder with a file
4. Press l to go into the subfolder
5. Try to close the mini.files buffer with "ZZ"
6. Error pops up, any attempt to press l on the folder again fails.

minimal.lua:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "https://github.com/folke/lazy.nvim.git",
        "--branch=stable", -- latest stable release
        lazypath,
    })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
    { "echasnovski/mini.nvim", version = false },
})

local mini_misc = require("mini.misc")
local fallback = function(buf_path)
    -- Just cd to the parent folder if you can't find a root marker
    return vim.fn.fnamemodify(buf_path, ":h")
end
mini_misc.setup_auto_root({ ".git", "package.json", "Makefile" }, fallback)
require("mini.files").setup()
vim.keymap.set("n", "<Leader>of", function()
    MiniFiles.open(vim.api.nvim_buf_get_name(0))
end, { desc = "[O]pen [F]ile tree" })

Expected behavior

mini.files closes normally as if the user had pressed q.

Actual behavior

Error executing vim.schedule lua callback: ...ddes/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1260: Invalid window id: 1003               
stack traceback:
        [C]: in function 'nvim_win_get_buf'
        ...ddes/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1260: in function 'explorer_refresh'
        ...ddes/.local/share/nvim/lazy/mini.nvim/lua/mini/files.lua:1774: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

[echasnovski]

Thanks for the issue!

I can reproduce, but closing single window is not a proper way of closing explorer in 'mini.files'. That would be with a config.mappings.close keys which is q by default.

Since 274c6ed4892802750284c92c7cc2c0b943343d85, closing single window will eventually result into closing whole explorer in the same way as any lost focus functionality. But again, this is not the supported way of closing explorer.

I'll look into it to at least not result into an error.

[Anthony-Fiddes]

I see what you're saying. I guess I'll add a after/ftplugin/minifiles.lua remap for ZZ to q. I just want minifiles to gracefully close with both the intended keymap and the one I'm used to using.

Perhaps there could be an official recommendation for how to add multiple mappings for one minifiles concept (e.g., maybe we could assign a table for each mapping, or maybe ftplugin would be the recommended way to add extra maps).

Edit: Just realized that that will remap ZZ to q for other windows as soon as I open a minifiles window. I'm sure I can fix it up though.

[Anthony-Fiddes]

Oh I see that you actually had an example in your docs of how to do this. Thanks for creating a lovely plugin and docs.

Here's the snippet that I ended up using, very similar to what was in the docs:

vim.api.nvim_create_autocmd("User", {
  pattern = "MiniFilesBufferCreate",
  callback = function(args)
    vim.keymap.set("n", "ZZ", "q", { buffer = args.data.buf_id, remap = true })
  end,
})

[echasnovski]

Here's the snippet that I ended up using, very similar to what was in the docs:

I'd recommend mapping explicitly to MiniFiles.close() with something like vim.keymap.set("n", "ZZ", function() MiniFiles.close() end, { buffer = args.data.buf_id }).

[echasnovski]

Thanks again for the issue!

It was not really about ZZ per se, but that the single not first window was closed not properly. This should now be solved on latest main branch.