which-key configuration causes bug when using embark-completing-read-prompter on regular buffer

[iyefrat]

When using the default which-key configuration, using emark-act in a regular buffer, calling embark-completing-read-prompter and then quitting it with C-g causes the cursor to stay on the inactive minibuffer, causing most keybindings to not work unless you click on another window with your mouse.

To reproduce, open emacs -Q and eval the following:

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)
(package-refresh-contents)
(package-install 'embark)
(require 'embark)
(package-install 'which-key)
(require 'which-key)
(global-set-key (kbd "C-S-a") #'embark-act)
(setq embark-action-indicator
      (lambda (map _target)
        (which-key--show-keymap "Embark" map nil nil 'no-paging)
        #'which-key--hide-popup-ignore-command)
      embark-become-indicator embark-action-indicator)

Then on some regular buffer do C-S-a C-h C-g, the cursor should be on the Canceled minibuffer and most keybindings won't work. Alternatively you can do (setq embark-prompter #'embark-completing-read-prompter) and then just do C-S-a C-g. This does not occur without the which-key configuration.

cc: @Zetagon @hugonobrega

[oantolin]

Weird one! The only problem is that the cursor stays in the minibuffer, right? When I tried it, I could use other-window to escape the minibuffer and everything else seemed fine.

[Zetagon]

The only problem is that the cursor stays in the minibuffer, right?

Yes, that seems to be it.

I could use other-window to escape the minibuffer

This is what I (and probably hugonobrega and iyefrat) get for using evil-mode haha. I didn't even think of using C-x o to get out of the minibuffer. "hjkl and the leader doesn't work!"

[iyefrat]

The only problem is that the cursor stays in the minibuffer, right?

Yeah, coupled with the fact that only minibuffer-inactive-mode-map seems to be active, so pressing ESC doesn't do anything which is my usual goto in these types of situations. However, trying to run abort-recursive-edit with C-] also doesn't do anything, probably because the minibuffer is inactive or something.

[hugonobrega]

According to my tests this fixes it, and I don't believe it introduces any new problems (famous last words, of course):

(setq embark-action-indicator
      (lambda (map _target)
        (which-key--show-keymap "Embark" map nil nil 'no-paging)
        (lambda ()
	  (kill-buffer which-key--buffer))))

[minad]

Just fyi, there are also the which-key issues #139 and #154.

[hugonobrega]

Indeed, to me at least #154 seems likely to be another symptom of the same thing (I didn't look much into #139)

[minad]

Yes, when I originally saw this issue, I thought it is a duplicate of #154. But I didn't look closer since I've stopped using which-key.

[oantolin]

I incorporated the (kill-buffer which-key--buffer) fix into the new which-key indicator, updated for the new indicator protocol! it now updates for prefix keys too!

[iyefrat]

Thanks!