which-key stop working after enter rust file inside rust project with fzf-lua

[towry]

Checklist

• [X] I have searched through the AstroNvim documentation
• [X] I have searched through the existing issues of this project
• [X] I have searched the existing issues of plugins related to this issue
• [X] I can replicate the bug with the minimal repro.lua provided below

Neovim version (nvim -v)

NVIM v0.11.0-dev-build-20231109-2186-gdafd944a4

Operating system/version

macos 14.5

Terminal/GUI

kitty

Describe the bug

This issue maybe related to the community plugin rust and fzf-lua.

Inside a git repo (files must be unstaged) rust project, use fzf-lua to open a rust file, then try to use the leader key to trigger which-key, which-key doesn't show up.

Steps to Reproduce

do not enter insert mode in rust file.

1. create this rust project by cargo new --bin foo
2. cd foo
3. the files should be unstaged.
4. please create init.lua inside foo.
5. nvim --clean -u init.lua
6. press <leader>ff open fzf-lua picker and select src/main.rs with arrow key, then <cr> to open it.
7. In main.rs, the rust lsp should be working.
8. try press leader key, the which-key doesn't show up.

Expected behavior

The which-key should show up when press leader key.

Screenshots

https://asciinema.org/a/7LviQ7wlduLpd7gmQoepu7t5t

Additional Context

1. This issue related to the rust pack, is because if you press leader key, it will show which-key, and then you open main.rs, press leader key, it won't show which-key.
2. if you enter insert mode, then it will trigger which-key.

Minimal configuration

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
    vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  -- stylua: ignore
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(vim.env.LAZY or lazypath)

-- install plugins
local plugins = {
    { "AstroNvim/AstroNvim", import = "astronvim.plugins" },
    { "AstroNvim/astrocommunity" },
    { import = "astrocommunity.pack.rust" },
    { import = "astrocommunity.fuzzy-finder.fzf-lua" },

    -- add any other plugins/customizations here
}
require("lazy").setup(plugins, {
    root = root .. "/plugins",
})

-- add anything else here (autocommands, vim.filetype, etc.)

[Uzaaft]

Can't reproduce.

[Uzaaft]

sanity question: Do you have rust-analyzer installed?

[Uzaaft]

Also, make sure your neovim is a stable one

[towry]

sanity question: Do you have rust-analyzer installed?

Do you followed the repro steps exactly? The lsp need to be working to repro this.

[towry]

Can repro in nvim v0.10.0, can not repro with LazyVim.

[Uzaaft]

I did follow the steps. :)

[Uzaaft]

Is everything up to date

[Uzaaft]

Could be that having the init.lua inside the same folder as the rust projects messes up things due to rust-analyzer indexing it. Try without the --clean flag. :)

[Uzaaft]

Adding in the two plugins into the minimal template provided by astronvim works fine. :)

[Uzaaft]

can confirm that I can replicate this only if the --clean flag is added to the nvim command . Not sure tbh if this is something we can fix

[towry]

Maybe report to the upstream plugin, but don't know which one to report. Which-key have bugs that related to the keymap that set <space> to <nop> which would cause which-key to not work, but I couldn't find any plugin that do this by ripgrep inside the lazy plugin folder. Also, localleader doesn't trigger wk too.

And can't repro with a minimal lazyvim setup, otherwise I would report to folke.

[Uzaaft]

I'm honestly not sure. @mehalter Any input?

[mehalter]

I don't have anything to add here. It seems like a which key bug and should be much more deeply investigated to figure out what is going on to be able to formulate a compelling issue upstream. --clean tells neovim to completely use stock settings and ignore all plugins. Basically "clear the runtime path". This means all core, built in plugins are ignored. This is not something that should break which-key but it could if the developer doesn't realize it relies on some random plugins bundled with neovim. It just needs to be investigated more to figure out what's going on, but I'm like 99% certain based on the information here it's unrelated to AstroNvim/AstroCommunity

[towry]

After some bisect debug, just find out the issue is located at https://github.com/AstroNvim/AstroNvim/blob/7d7e3f124d7789233f3faf200980a6ca36f11174/lua/astronvim/plugins/_astrocore_autocmds.lua#L146

If i remove this autocmd, the issue is gone.

To be more clear, the conditions to trigger this bug is:

1. open file with fzf-lua.
2. no --clean is needed.
3. the file should not be git staged.
4. with rust lsp is working.
5. no insert mode trigger after enter the rust file.

[mehalter]

@towry if you did a bisect, what commit did you find was the offending one?

[mehalter]

oh you were just removing things, not doing a git bisect

[mehalter]

@towry that makes total sense that removing that auto command would solve some random bug 😅 It's probably which-key bug interacting with things like plugins getting loaded and that auto command would effectively make basically no plugins in astronvim load

[mehalter]

@towry I found it has something to do with our autocommand triggering which is causing which-key to get into some weird state where it isn't triggering. This is definitely a which-key bug not properly setting up it's triggering. If you do some other operation like go to another window and come back then it starts working again in that main window 🤷🏼 I don't understand what's happening with which-key which is making it hard for me to open an issue upstream

[mehalter]

Ok, I reduced this down to a repro.lua file and attempted an issue. Hopefully it's well formed enough to get it figured out. Definitely a strange edge case it seems 🤷🏼

https://github.com/folke/which-key.nvim/issues/787

[towry]

Can confirm it is working normal after updating the which-key plugin to the latest head commit.

Thanks.