[feature request] Backspace back to upper level + don't break at nonexist keymap about vim-which-key HOT 7 CLOSED

Your points make sense. Try #56 and let me if you run into some error.

from vim-which-key.

I noticed it started to behave strangely after I typed an invalid key.

1. <backspace> works well only when the keys I typed so far are correct.
2. The invalid keys are really simply ignored right now. Even <backspace> does not delete them. Typing other invalid keys between a valid key mapping still works.

I am using the latest 'allow-backspace-to-upper-level' branch.

from vim-which-key.

There is no delete action essentially. Every single invalid key is ignored since vim-which-key responses to your each input char and doesn't remember your previous input.

Typing other invalid keys between a valid key mapping still works.

Can you elaborate?

from vim-which-key.

There is no delete action essentially. Every single invalid key is ignored since vim-which-key responses to your each input char and doesn't remember your previous input.

But the keys typed are shown down in the command window, sometimes the behavior will be inconsistent.
Suppose I have <leader>g sub-dict but don't have <leader>ga key mapping. And now do the following steps:

1. Type <leader>, a window pops up.
2. Type g will go to the sub-dict as expected.
3. Then type a, nothing happens also as expected.
4. Then <backspace>, now a will be 'deleted' in the prompt (leaves <leader>g) and it goes to the upper level dict (as in step 1). In other words, now I am in <leader> level, but it shows <leader>g.

I think g should've been deleted but it was a because it was the last letter typed.

Typing other invalid keys between a valid key mapping still works.

Can you elaborate?

Suppose I have <leader>cc as a key mapping but no <leader>z*. Then if I type <leader>zcc, the key mapping of <leader>cc will work.

from vim-which-key.

But the keys typed are shown down in the command window, sometimes the behavior will be inconsistent.

Pull the latest commit of #56, should be fixed.

Suppose I have cc as a key mapping but no z*. Then if I type zcc, the key mapping of cc will work.

As a matter of fact, if you type zcc in one shot, it will be considered as invalid keys. If you type z and then cc, z will be ignored silently and cc will work as expected. So your point doesn't hold.

from vim-which-key.

Yes, blocking the invalid keys has solved all the issues! I think it works perfectly regarding the feature request.

BTW, maybe a irrelevant issue, if I hold on a invalid key for some time, there will be a pile of error messages popping up. The last one is "E132: Function call depth is higher than 'maxfuncdepth'".
Update: the errors also appears when I do something like <leader>g<BS>g<BS>(for just a dozen times).

from vim-which-key.

The E132 issue you point out is not the normal case and may won't be fixed.

from vim-which-key.