Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keymaps have stopped working when disabling which-key for ft=grug-far #419

Open
rami3l opened this issue Mar 15, 2025 · 3 comments
Open

Comments

@rami3l
Copy link

rami3l commented Mar 15, 2025

First of all, I want to say thank you for making this wonderful plugin! It has made replace/search a joy in my text-based dev setup 🙏

Sorry for filing this issue here since I'm not completely sure whether this is a problem with this plugin in particular, but starting from a certain commit, my grug-far won't accept default hotkeys any more.

For example, g? will no longer show the help menu, and ,r will no longer perform the replace action.

My manual bisection has confirmed that #372 is the breaking change in question.

As I'm using AstroNvim's grug-far bundle, I have investigated further and have found out that if I comment out the following section, the hotkeys will start working again:

    {
      "folke/which-key.nvim",
      optional = true,
      opts = function(_, opts)
        if not opts.disable then opts.disable = {} end
        opts.disable.ft = require("astrocore").list_insert_unique(opts.disable.ft, { "grug-far" })
      end,
    }

https://github.com/AstroNvim/astrocommunity/blob/0ad87f5d6f03334518c7df6d4b6e0737a86c045b/lua/astrocommunity/search/grug-far-nvim/init.lua#L87-L94

... this snippet basically disables which-key for ft=grug-far. I suspect that, due to a change in the initialization order in #372, grug-far's own keybindings have been wiped out as well?

I can forward this to which-key as well if necessary. Many thanks in advance!

@xieyonn
Copy link
Contributor

xieyonn commented Mar 15, 2025

It seems to be a plugin conflict issue.

The which-key plugin has intercepted your key input, that's the reasone why g? not work. You can use command verbose map g? in grug-far window to check if this shortcut key exists. I guess the shortcut is still exist, not wiped.

It would be better if you could provide a minimal reproducible configuration.

I made this commit #372. This is my debugging thought process, for your reference:

  1. In the AstroNvim's grug-far configuration you are using, the which-key plugin needs to be disabled. see this pr https://github.com/AstroNvim/astrocommunity/pull/1212/files#diff-994dffa9bfae0ec58bf9611afca879cdb6bdad8b09321afa3ecf09f9d83c2e79R92
    {
      "folke/which-key.nvim",
      optional = true,
      opts = function(_, opts)
        if not opts.disable then opts.disable = {} end
        opts.disable.ft = require("astrocore").list_insert_unique(opts.disable.ft, { "grug-far" })
      end,
    }
  1. which-key plugin uses the BufEnter event to set the disabled filetype config.
    Step1: https://github.com/folke/which-key.nvim/blob/main/lua/which-key/state.lua#L143
vim.api.nvim_create_autocmd({ "BufEnter" }, {
    group = group,
    callback = function(ev)
      current_buf = ev.buf ---@type number
      Util.trace(ev.event .. "(" .. ev.buf .. ")")
      Buf.get() 
      Util.trace()
    end,
  })

https://github.com/folke/which-key.nvim/blob/main/lua/which-key/buf.lua#L218

function M.get(opts)
  M.cleanup()
  opts = opts or {}
  local buf = opts.buf or vim.api.nvim_get_current_buf()

  if not vim.api.nvim_buf_is_valid(buf) then
    return
  end

  local ft = vim.bo[buf].filetype
  local bt = vim.bo[buf].buftype

  if vim.tbl_contains(Config.disable.ft, ft) then
    return
  end
  if vim.tbl_contains(Config.disable.bt, bt) then
    return
  end

  M.bufs[buf] = M.bufs[buf] or Buf.new(buf)
  return M.bufs[buf]:get(opts)
end
  1. Due to this commit fix: can not get correct winid in FileType callback #372, we bind buf to win first, which trigger BufEnter event, thus in the BufEnter event callback, the filetype is empty. As a result, the which-key disable for filetype grug-far not work.

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.

If you are not using the which-key plugin, you can just delete this configuration.

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 .

@rami3l
Copy link
Author

rami3l commented Mar 15, 2025

@xieyonn Thanks a lot for your detailed analysis.

I have filed folke/which-key.nvim#960 with a minimal reproduction to see whether that is an appropriate approach first.

@MagicDuck
Copy link
Owner

MagicDuck commented Mar 16, 2025

thanks for handling this one @xieyonn !

The only thing that I would add is that the config that @rami3l mentions is likely a hold over from "olden times" when which-key caused folds not to work correctly in grug-far, but that issue has been resolved for some time. So I think it can be removed from the astrovim grug-far bundle. 👇

        if not opts.disable then opts.disable = {} end
        opts.disable.ft = require("astrocore").list_insert_unique(opts.disable.ft, { "grug-far" })

which-key works well with grug-far atm (when not disabled, haha :))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants