bug: conflict with `grug-far.nvim` when disabling `which-key` for `ft=grug-far`

[rami3l]

Did you check docs and existing issues?

• [x] I have read all the which-key.nvim docs
• [x] I have updated the plugin to the latest version before submitting this issue
• [x] I have searched the existing issues of which-key.nvim
• [x] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.4 (Build type: Release, LuaJIT 2.1.1741730670)

Operating system/version

macOS Sequoia 15.3.2 (24D81, arm64)

Describe the bug

As originally reported in https://github.com/MagicDuck/grug-far.nvim/issues/419#issuecomment-2726321135, if I disable which-key for ft=grug-far, grug-far won't accept default hotkeys any more. This has basically rendered the :GrugFar panel unusable.

A possible minimal reproduction repro.lua is shown further below.

Following @xieyonn's suggestion in https://github.com/MagicDuck/grug-far.nvim/issues/419#issuecomment-2726321135, I decided to cross-post it here.

Steps To Reproduce

1. Run nvim -u repro.lua.
2. Run :GrugFar followed by <Esc> to enter normal mode.
3. Test the hotkey g?, noticing that the help menu is not shown.
4. Comment out the line indicated in the above snippet and retest, noticing that this time the help menu is showing up as expected.

Expected Behavior

g? should be triggered, activating grug-far's help menu regardless of whether opts.disable.ft is set or not.

Health

which-key: require("which-key.health").check()

- OK Most of these checks are for informational purposes only.
  WARNINGS should be treated as a warning, and don't necessarily indicate a problem with your config.
  Please |DON'T| report these warnings as an issue.

Checking your config ~
- WARNING |mini.icons| is not installed
- WARNING |nvim-web-devicons| is not installed
- WARNING Keymap icon support will be limited.

Checking for issues with your mappings ~
- OK No issues reported

checking for overlapping keymaps ~
- WARNING In mode `n`, <gc> overlaps with <gcc>:
  - <gc>: Toggle comment
  - <gcc>: Toggle comment line
- OK Overlapping keymaps are only reported for informational purposes.
  This doesn't necessarily mean there is a problem with your config.

Checking for duplicate mappings ~
- OK No duplicate mappings found

Log

Debug Started for v3.17.0
{
  branch = "main",
  commit = "370ec46f710e058c9c1646273e6b225acf47cbed"
}
new Mode(n:1)
Trigger(add) Mode(n:1) " ` ' g' g` z= g ] [ z <C-W>
on_key: :
ModeChanged(n:c)
  new Mode(c:1)
  Safe(true)
Trigger(add) Mode(c:1) <C-R>
on_key: G
on_key: r
on_key: u
on_key: <Tab>
on_key: <CR>
ModeChanged(c:n)
  Unsafe(command-mode)
  suspend: Mode(n:1)
  Trigger(del) Mode(n:1) ` ' g' g` z= <C-W> g ] [ z "
BufNew(3)
BufEnter(3)
  new Mode(n:3)
Trigger(add) Mode(n:1) " ` ' g' g` z= g ] [ z <C-W>
Trigger(add) Mode(n:3) " ` ' g' g` z= g ] [ z <C-W>
ModeChanged(n:i)
  Safe(true)
on_key: <Esc>
ModeChanged(i:n)
  Safe(true)
on_key: g
State(start): Mode(n:0) Node(g) { keys = "g" }
  no mode
on_key: ?
ModeChanged(n:c)
  Safe(true)
on_key: <Esc>
ModeChanged(c:n)
  Unsafe(command-mode)
on_key: :
ModeChanged(n:c)
  Safe(true)
on_key: q
on_key: !
on_key: <BS>
on_key: a
on_key: !
on_key: <CR>
ModeChanged(c:n)
  Unsafe(command-mode)

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    { "MagicDuck/grug-far.nvim", cmd = "GrugFar" },
    { "folke/which-key.nvim", opts = { disable = { ft = {
        -- Comment out the following line, and `:GrugFar` followed by `g?`
        -- (in normal mode) will work properly again:
        "grug-far",
    } } } },
  },
})

Remarks

My apologies for not being familiar with Neovim plugin development, so I don't have a standpoint regarding if this is a bug or an intended behavior, and which should be the more appropriate approach to take in the former case.

However, I would like to quote @xieyonn's analysis in the original issue which I believe has pointed out a possible path forward:

I think this problem is caused by the fact that different plugins sense the filetype in different way. Some directly use the FileType event, some use the BufEnter event. Personally, I don't think it's a good idea to use the BufEnter event to determine the filetype, because according to the description in the documentation, BufEnter is a good opportunity to modify the filetype, rather than to read it.

[..]

I think a PR should be submitted to the which-key plugin, and the update of disable.ft should be placed in the callback of the FileType event . https://github.com/MagicDuck/grug-far.nvim/issues/419#issuecomment-2726321135

I didn't submit the PR directly because I would like to know whether that's an acceptable thing to do at first. Many thanks in advance!

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[rami3l]

Sorry, but this is still needed...

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[rami3l]

Still needed :)

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[Thibaulltt]

Seems to be the disabling on certain filetypes which does not work. Disabling which-key for help buffers disables the 'gO' keymap on my setup, preventing me from opening the help outline.

It also prevents any window movements (<C-W>{motion}) in interactive treesitter windows (EditQuery, InspectTree) if which-key is disabled on 'nofile' buftypes.

[rami3l]

Sorry bot, this is still needed.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.