Persistent `which-key` minibuffer which does not quit with `C-g`?!

[zenny]

Hi @pprevos

I am actively trying EWS to work with because this config seems sane for my specific purpose. :) Yet there are some visual issues that I have encountered and reporting. Maybe it could be my fault. Apology in advance in the later case.

On times, the which-key minibuffer does not go away (quit) as seen in the screenshot with highlighted text below when org-refile (C-c C-w) is used to refile a section from one header to the other. Pressing C-g to quit the minibuffer has no effect, Pressing Esc pops up another minibuffer. The only way to close the which-key minibuffer in such a case is to use C-x 0. Or did I miss something?

Messages shows the following:

Refile to "3rd header" in file /home/zenny/Documents/notes/20240725T193021--first-test__test.org: done
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Getting targets...done
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Copied: Subtree(s) with 287 characters
Saving file /home/zenny/.ihsec/ews/bookmarks...
Wrote /home/zenny/.ihsec/ews/bookmarks
Saving bookmarks to file ~/.ihsec/ews/bookmarks...done
Refile to "3rd header" in file /home/zenny/Documents/notes/20240725T193021--first-test__test.org: done
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Quit
Auto-saving...done
Mark set
Wrote /home/zenny/.ihsec/ews/recentf
Mark set
End of buffer [2 times]
Mark set

Thanks again.

Cheers, /z

[pprevos]

Hi Zenny, I appreciate your issues because they help me better understand users and improve the config and the final version of the book.

The message log has some strange messages between these lines:

Getting targets...done
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Copied: Subtree(s) with 287 characters

When I use org-refile I get this:

Getting targets...done
Copied: Subtree(s) with 287 characters

In your case, a Dired process is doing things simultaneously. Could it have something to do with your left window? Which package is this?

[zenny]

Hi Zenny, I appreciate your issues because they help me better understand users and improve the config and the final version of the book.

My pleasure.

The message log has some strange messages between these lines:

Getting targets...done
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Marking matching files...
3 matching files marked
Hid 3 dotfiles.
Copied: Subtree(s) with 287 characters

When I use org-refile I get this:

Getting targets...done
Copied: Subtree(s) with 287 characters

In your case, a Dired process is doing things simultaneously. Could it have something to do with your left window? Which package is this?

dired-sidebar from https://github.com/jojojames/dired-sidebar which has been configured as of below, fyi. I use dired-sidebar for easy navigation of folders than keep on pressing C-x d or C-x C-d each time to invoke dired. Above all, it is easily hidden/collapsible with C-x C-n. I find it easier.

(use-package dired-sidebar
  :bind (("C-x C-n" . dired-sidebar-toggle-sidebar))
  :ensure t
  :commands (dired-sidebar-toggle-sidebar)
  :init
  (add-hook 'dired-sidebar-mode-hook
            (lambda ()
              (unless (file-remote-p default-directory)
                (auto-revert-mode))))
  :config

  (push 'toggle-window-split dired-sidebar-toggle-hidden-commands)
  (push 'rotate-windows dired-sidebar-toggle-hidden-commands)

  (setq dired-sidebar-subtree-line-prefix "__")
  (setq dired-sidebar-theme 'vscode)
  (setq dired-sidebar-use-term-integration t)
  (setq dired-sidebar-use-custom-font t))

[pprevos]

I added your config for dired-sidebar and could not replicate the error. I use the EWS config as published.

[zenny]

I added your config for dired-sidebar and could not replicate the error. I use the EWS config as published.

Thanks for testing. Fyi, I also do use EWS config as you have posted from the master, yet I am having that typical problem, do not know how?

[zenny]

Btw, the Backtrace minibuffer shows as of below when a similar situation recurred a while ago:

Debugger entered--Lisp error: (minibuffer-quit)
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_67>()
  #<subr completing-read-default>("M-x " #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_55> #f(compiled-function (sym) #<bytecode 0x11841ce966b61ee0>) t nil extended-command-history nil nil)
  apply((#<subr completing-read-default> "M-x " #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_55> #f(compiled-function (sym) #<bytecode 0x11841ce966b61ee0>) t nil extended-command-history nil nil))
  vertico--advice(#<subr completing-read-default> "M-x " #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_55> #f(compiled-function (sym) #<bytecode 0x11841ce966b61ee0>) t nil extended-command-history nil nil)
  apply(vertico--advice #<subr completing-read-default> ("M-x " #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_55> #f(compiled-function (sym) #<bytecode 0x11841ce966b61ee0>) t nil extended-command-history nil nil))
  completing-read-default("M-x " #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_55> #f(compiled-function (sym) #<bytecode 0x11841ce966b61ee0>) t nil extended-command-history nil nil)
  read-extended-command-1("M-x " nil)
  read-extended-command()
  byte-code("\302\30\11\303 \10)E\207" [execute-extended-command--last-typed current-prefix-arg nil read-extended-command] 3)
  command-execute(execute-extended-command)

Maybe this leads to somewhere?! Thanks again.

[zenny]

I have restarted emacs again with --debug-init (always do so) and M-x toggle-debug-on-error RET, I got the following when the which-key minibuffer stuck:

Debugger entered--Lisp error: (error "#<window 55> is not a live window")
  error("%s is not a live window" #<window 55>)
  window-normalize-window(#<window 55> t)
  unrecord-window-buffer(#<window 55> #<buffer  *which-key*>)
  quit-windows-on(#<buffer  *which-key*>)
  which-key--hide-buffer-side-window()
  which-key--hide-popup-ignore-command()
  which-key--hide-popup()
  which-key--update()
  apply(which-key--update nil)
  timer-event-handler([t 0 1 0 t which-key--update nil idle 0 nil])

[zenny]

@pprevos The culprit appears to be the dired-sidebar package which interferes with which-key and what not. Sorry for false alarm. Thanks for bearing with me. Cheers and have a nice weekend.

[pprevos]

I suspected as much. Thanks for letting me know.

[zenny]

Hi @pprevos,

Meanwhile, I loaded the dired-sidebar with exactly the same config to the Prof. John Kitchin's scimax config (https://github.com/jkitchin/scimax). Lo and behold, the minibuffer issue did not appear in that case, fyi.

[pprevos]

SciMax is similar to EWS in that it is for research and writing. John's config focuses more on technical writing and literate programming.

Since dired-sidebar is not part of EWS, I will close this issue.