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

Does not work with which-key.nvim #20

Closed
kevintraver opened this issue Aug 9, 2023 · 12 comments
Closed

Does not work with which-key.nvim #20

kevintraver opened this issue Aug 9, 2023 · 12 comments
Labels
bug Something isn't working

Comments

@kevintraver
Copy link

kevintraver commented Aug 9, 2023

When using cutlass with which-key, the remapped keys prevent which-key from opening the popup.

@gbprod
Copy link
Owner

gbprod commented Aug 11, 2023

Hey!
Thanks for opening this issue
I'm currently on vacation, I will check this when I come back 😉

@gbprod
Copy link
Owner

gbprod commented Sep 6, 2023

I think it's more of a limitation on the which-key side. As which-key comes with presets for default vim keys, it considers that there is a conflict. When running :checkhealth which-key, I have this :

- WARNING conflicting keymap exists for mode **"n"**, lhs: **"d"**
- rhs: `"_d`
- WARNING conflicting keymap exists for mode **"n"**, lhs: **"c"**
- rhs: `"_c`
....

It seems legit but I've tried to disable which-key presets like this :

local which_key = require("which-key")

which_key.setup({
  plugins = {
    presets = {
      operators = false,
      motions = false,
    },
  },
})

Or like this :

local which_key = require("which-key")
local presets = require("which-key.plugins.presets")
presets.operators["d"] = nil
which_key.setup({})

but it does not works....

Maybe @folke can help us on that ?
Maybe we should open an issue on which-key repo ?

@sebastianst
Copy link

Related to this, for me cutlass doesn't work at all if the which-key plugin is also enabled. The pop-ups of which-key show up, but the d and s bindings are just not set by cutlass. Seems like an ordering issue to me.

@sebastianst
Copy link

sebastianst commented Sep 11, 2023

@gbprod I think I fixed it by adding

  {
    "folke/which-key.nvim",
    opts = function(_, opts)
        opts.triggers_blacklist = {
            -- list of mode / prefixes that should never be hooked by WhichKey
            -- this is mostly relevant for keymaps that start with a native binding
            i = { "j", "k", "d", "D", "s", "S" },
            v = { "j", "k", "d", "D", "s", "S" },
            n = { "d", "D", "s", "S" },
        }
        return opts
    end,
  },

to .config/nvim/lua/user/core.lua (or any other lua file in that dir), which adds the keys that cutlass remaps to which-key's blacklist. Note that I use AstroNvim in this setup. The key here is to expand the triggers_blacklist option of which-key.

It would be nice if cutlass could be made which-key aware. If it detects which-key, it could configure the triggers_blacklist of which-key, and additionally add descriptions for the new bindings to which-key.

@gbprod gbprod added the bug Something isn't working label Oct 6, 2023
@b0ae989c
Copy link

Assuming we use lazy.nvim to manage plugins, a workaround for this issue is to set lazy = false for cutlass.

@gbprod
Copy link
Owner

gbprod commented Nov 30, 2023

I've just tried that but it doesn't works for me. I have which-key menu that appear, but cutlass mappings are not set :/

Maybe you have a more complete config to share @b0ae989c ?

@b0ae989c
Copy link

@gbprod Here is a minimal init.lua. Run with nvim -u init.lua with Neovim v0.9.4 on macOS, and cutlass.nvim works as expected.

local root = vim.fn.fnamemodify('./.repro', ':p')
for _, name in ipairs({ 'config', 'data', 'state', 'cache' }) do
  vim.env[('XDG_%s_HOME'):format(name:upper())] = root .. '/' .. name
end
local lazypath = root .. '/plugins/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',
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)
local plugins = {
  'folke/tokyonight.nvim',
  {
    'folke/which-key.nvim',
    event = 'VeryLazy',
  },
  {
    'gbprod/cutlass.nvim',
    lazy = false,
    config = true,
  },
}
require('lazy').setup(plugins, { root = root .. '/plugins' })
vim.cmd.colorscheme('tokyonight')

@z775729168
Copy link

z775729168 commented Dec 10, 2023

@b0ae989c It works, but which-key can't show the menu in visual mode.
If the key map is something like <leader>a, and it has a submenu, everything is fine, only the <leader> menu won't pop.
And it needs to be pressed fast enough, <leader> will become a normal space .

@b0ae989c
Copy link

b0ae989c commented Dec 10, 2023

<leader> will become a normal space

That's a separate issue. With the config above, <Leader> is the default key \.

@z775729168
Copy link

@b0ae989c

When using cutlass with which-key, the remapped keys prevent which-key from opening the popup.

I do not know why, but the plugin actually remaps s<space>.

if not cutlass.options.exclude["s<space>"] then
map("s", "<space>", string.format('<c-o>"%sc<space>', cutlass.options.registers.select), keymap_opts)
end

Add s<space> to config.exclude fix it.

@z775729168
Copy link

I am sorry, it seems I misunderstood something...
I tested the triggers_blacklist and layz=false, none of them worked with me.

Mini.operator has the same symptoms.

@kevintraver
Copy link
Author

This appears to be fixed with the latest version of cutlass and which-key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants