g:which_key_timeout doesn't seem to work

[ChristianChiarulli]

Just wondering if anyone else is experiencing this issue. I saw a comment back in may on a closed issue about this saying it wasn't working of them either.

No matter what I set this to the map always respects timeoutlen

Neovim version: NVIM v0.5.0-804-geee066881 Plugin Version newest just updated

[liuchengxu]

Can you help find which commit is the last one that works as expected?

[ChristianChiarulli]

Can you help find which commit is the last one that works as expected?

I'll probably have time later this week to test out a few

[smichaud]

Weirdly enough, I discovered the plugin by watching @ChristianChiarulli youtube video. I had the same issue, and I remove the set notimeout from my vimrc, which solved the problem ¯\_(ツ)_/¯. This is contradictory to the documentation...

[farzadmf]

@ChristianChiarulli did you manage to figure this out?

BTW, loved your tutorial videos about neovim on YouTube; I'm sad there's not many more :slightly_frowning_face:

[farzadmf]

Weirdly enough, I discovered the plugin by watching @ChristianChiarulli youtube video. I had the same issue, and I remove the set notimeout from my vimrc, which solved the problem ¯\_(ツ)_/¯. This is contradictory to the documentation...

@smichaud I think that's the expected behavior, and in the screenshot you provided, it says "all you need is not to set notimeout", which is the same as what you did: remove it from your vimrc :slightly_smiling_face:

[gquittet]

It doesn't work on my side with Neovim. My timeoutlen is on and use the default value (aka 1000) and I defined the g:which_key_timeout to 100

Unfortunately I have to wait 1 second before seeing the which key popup.

https://github.com/liuchengxu/vim-which-key/issues/3#issuecomment-622965328

[liuchengxu]

Not sure what you are expecting, g:which_key_timeout does not change timeoutlen and is merely used to detect if there are more keycode sequences to complete, see https://github.com/liuchengxu/vim-which-key/issues/3#issuecomment-427535013. If you only change g:which_key_timeout to 100, and the which key popup shows up until 1 second later, that's expected.

[farzadmf]

One change that I noticed when I set the timeout is this. Let's consider an example where I need to press <leader> + w + a + q:

• If I don't set g:which_key_timeout = 100, and If I do everything "fast", which-key popup doesn't appear at all
• If I have let g:which_key_timeout = 100, when I press <leader>, it would take timeoutlen for the popup to appear, but when I press <leader> and w, then the popup will appear no matter how fast I am

I think this behavior makes sense and I'm personally OK with this. I'd personally like to see the popup as soon as I pressed something, so I had set timeoutlen=100, but then, I was having problems, say, with gg to move and I had to do the combination in less than 100ms, which I think everyone agrees is too fast.

I decide to also bind g to which-key, but then the mappings didn't work anymore.

So, long story short, as I said, I'm personally OK with the behavior as is right now, and I think it's a good compromise.

[gquittet]

OK nice! I haven't understand the settings like this. Now, it's clear to me.

Is it possible to show the which key menu instantly without editing the timeoutlen setting ?

[liuchengxu]

Is it possible to show the which key menu instantly without editing the timeoutlen setting ?

Nope. Even there is some hack to do that, I think it can bring more harm than good.

[folke]

fyi: @farzadmf you can make the g mappings work by additionally setting the option vim.g.which_key_fallback_to_native_key = 1

[farzadmf]

Thank you @folke , I'll give it a try