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

feat(win): use which-key for toggle_help when available #745

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

minusfive
Copy link
Contributor

Description

Leverage which-key to show the help window when available.

Related Issue(s)

N/A

Screenshots

Screen.Recording.2025-01-24.at.13.00.03.mov
Screen.Recording.2025-01-24.at.13.01.02.mov

@github-actions github-actions bot added the win label Jan 24, 2025
@minusfive minusfive force-pushed the win-use-which-key-for-help branch from a549adf to 1d780f3 Compare January 24, 2025 18:16
@dpetka2001
Copy link
Contributor

dpetka2001 commented Jan 24, 2025

Scrolling the which-key window with <C-d>/<C-u> doesn't work in helix mode, because it scrolls the list window of the picker, so you can't see the rest of the keys on which-key except the ones that show up initially. If you want to go forward with this, then I'd suggest make it configurable with an option so that users can choose what they want.

@minusfive
Copy link
Contributor Author

@dpetka2001 good catch! I'll dig into why / how it works in normal windows, where it takes over those mappings when they collide.

Providing an option is definitely something I thought about, but would like to discuss it further. I mean, it'd be easy, but which-key has already solved many problems the built-in help window / layout still has, and has many more features / options out of the box.

So my thinking was: if a user already "opted in" to using wk, then it'd be nice if that was used instead of the built-in by default, and gives them a more consistent experience to boot. Of course these keymap collisions (and any remaining bugs) will need to be ironed out, but I suspect this will be an easier task than re-solving everything wk already has with the built-in.

That said, it may be a good idea to expose wk's options regardless, so users can configure this specific instance as granularly as they like, with it inheriting the global wk options by default. Will look into it.

@dpetka2001
Copy link
Contributor

So my thinking was: if a user already "opted in" to using wk, then it'd be nice if that was used instead of the built-in by default, and gives them a more consistent experience to boot.

I've seen lots of strange stuff from users. Making it configurable would avoid any future issues. Some people might still prefer the builtin help menu instead of the which-key one and they should be able to make the choice even if they have which-key installed.

@zinobobo418
Copy link

Ja

@lalvarezt
Copy link

with the current implementation calling the toggle_help function a second time doesn't hide it. From what I can see in the you call the show function every time, perhaps a check to see if which_key is already active can solve this

@lalvarezt
Copy link

why not do something like this and leave the user the option to bind it to whatever they want

return {
  "folke/snacks.nvim",

  opts = {
    picker = {
      -- default unless overridden, can be placed inside any picker
      win = {
        input = {
          keys = {
            ["<F12>"] = {
              function()
                require("which-key").show({ global = false })
              end,
              desc = "Show which-key",
              mode = { "n" },
            },
          },
        },
      },
    },
  },
}

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

Successfully merging this pull request may close these issues.

4 participants