Keyboard + Command hints stop showing

[ro6]

Description :octocat:

The hints that show what keys map to what commands no longer pop up along the bottom of the screen. It's fine at first, but somehow I get into a state where it no longer pops after that.

Reproduction guide :beetle:

• Restart emacs and restore prior layouts state (I'm usually doing SPC-q-r)
• Start a Cider session with , '
• Hit leader key (,)
• Wait a while, but nothing shows up indicating what keys might follow leader. Same for all others that should, like SPC, or even combinations like SPC-f.

Observed behaviour: :eyes: :broken_heart: I see confirmation of the leader key that was entered, but no menu of next possible keys and commands.

Expected behaviour: :heart: :smile: The display of next possible command keys and commands.

System Info :computer:

• OS: windows-nt
• Emacs: 29.2
• Spacemacs: 0.999.0
• Spacemacs branch: develop (rev. 2dadee571)
• Graphic display: t
• Running in daemon: nil
• Distribution: spacemacs
• Editing style: hybrid
• Completion: helm
• Layers:

  (python javascript html groovy auto-completion better-defaults
      (clojure :variables clojure-toplevel-inside-comment-form t clojure-backend 'lsp clojure-enable-linters
               '(clj-kondo joker))
      cmake common-lisp emacs-lisp git helm kotlin
      (lsp :variables lsp-lens-enable nil lsp-headerline-breadcrumb-enable nil)
      markdown
      (shell :variables shell-default-height 30 shell-default-position 'bottom)
      spacemacs-layouts syntax-checking windows-scripts treemacs
      (zig :variables zls-backend 'lsp)
      version-control)

• System configuration features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

[practicalli-johnny]

The cause may be a temporary issue with the which-key package.

Edit: this is a change to how helm-descbinds package works which conflicts with which-key package. I will pin the Melpa recipe for the older package before the change

I experienced the same issue today with a newly installed Emacs 29.2 (Emacs Plus) and a git pull --rebase in the Spacemacs config.

I removed my own Spacemacs user config and restarted Emacs so Spacemacs prompted for Evil/Hold and distribution.

Pressing SPC whist in the home buffer showed the main Spacemacs whichkey menu. After opening a few files and running commands, the which-key menu stopped working pretty quickly.

Somehow I triggered Spacemacs to download all the packages again for Emacs 29.2 and the whichkey menu seems to be working consistently now, SPC and , menus.

Consider deleting the which-key package from .emacs/elpa/29.2/develop/ directory and restarting Emacs to download the package again (or delete all packages and start again for a more aggressive approach)

[davidpiano]

Same problem here on Emacs 30. I deleted which-key to force it to be reinstalled, but it's still not working. However, I may have changed some of which-key's settings while trying to fix this problem, and I'm not sure how to make sure I've unset them all back to default.

[dankessler]

For me, it seems like it perhaps has something to do with helm. If I fire up emacs and try various keys but am careful to not trigger helm, then which-key keeps popping up correctly for me. If I cause the helm completion buffer to show up (e.g., with SPC SPC or M-x) and either back out of that (with C-g) or finish whatever I'm doing in helm, then which-key enters the "broken" state described above.

[kirill-snap]

I removed which-key rm -rf ~/.emacs.d/elpa/29.2/develop/which-key-20230905.2128 and restarted emacs. Issue still exists

[dankessler]

I even more aggressively cleaned things up by running git clean -dxff in my emacs config directory and the issue still persists

[johnnywalker]

I tried removing which-key and then tried removing the entire ~/.emacs.d/elpa/29.1/develop directory. Nothing helped. I played around with various which-key-* functions via M-x and somehow triggered the which-key popup. I had to manually close the window, but it began working normally after :q or SPC w d.

I removed ~/.emacs.d/.cache/layouts/persp-auto-save in case the window layout was somehow corrupted, but the problem recurred. I used SPC SPC (M-x) to run which-key-show-next-page-cycle, closed the displayed mini window, and which-key resumed normal operation.

I'm not sure how repeatable this is, but I wanted to share in case it helps troubleshoot.

UPDATE: I wouldn't recommend repeating any of these steps now. I just jotted them down previously when the bug was still at large.

[gfr-g]

the bug is caused by this change https://github.com/emacs-helm/helm-descbinds/commit/d1c46d56455d2956f173f94016fe7a2929606766

[kirill-snap]

@gfr-g you were right. I reverted changes manually in this file ~/.emacs.d/elpa/29.2/develop/helm-descbinds-20240206.802/helm-descbinds.el and then restarted emacs. Looks like it works now.

[sthysel]

Replacing ~/.emacs.d/elpa/29.2/develop/helm-descbinds-20240206.802/helm-descbinds.el with the previous version from https://github.com/emacs-helm/helm-descbinds/blob/67b299116f31a8f038d9f427864d91916eb95e0d/helm-descbinds.el worked for me, thanks @gfr-g / @kirill-snap

[James-Hanson]

Replacing ~/.emacs.d/elpa/29.2/develop/helm-descbinds-20240206.802/helm-descbinds.el is not working for me. I tried it on two Linux installations, including a completely fresh copy of Ubuntu.

Specifically, , is not working in LaTeX mode. Also, when I do SPC m-, nothing happens and I get the message SPC m- which-key: There are no keys to show in the messages buffer.

[stkain]

FYI,

so as of current state (helm-descbinds of elpa/29.2/develop/helm-descbinds-20240212.640) both which-key-mode and helm-descbinds-mode don't work together. When I have which-key-mode disabled and helm-descbinds-mode enabled, the key-completion help does not show up if I have which-key-mode enabled and helm-descbinds-mode disabled, I get the key-completion help again

[johnnywalker]

Given the feedback from helm-descbinds, I added this to ~/.spacemacs:

(defun dotspacemacs/user-config ()
  ;; `helm-descbinds-mode' cannot be used with `which-key-mode', but both are loaded automatically
  ;; by default. See https://github.com/emacs-helm/helm-descbinds/issues/32#issuecomment-1936969435
  (eval-after-load "helm-descbinds"
    '(when helm-descbinds-mode
       (message "Disabling 'helm-descbinds-mode' and enabling 'which-key-mode'")
       (remove-hook 'helm-mode-hook 'helm-descbinds-mode)
       (helm-descbinds-mode -1)
       (which-key-mode 1)))
)

I'm not well versed in Emacs Lisp, but this is working well for me so far.

[dankessler]

@johnnywalker I think you're on the right track, but your fix didn't work for me. I suspect that it's because when the helm-descbinds file is loaded (which triggers the form stashed away with eval-after-load), helm-descbinds-mode isn't (yet) enabled, so the when block doesn't actually run, and I'm surprised it's working for you.

A very simple fix that is working for me is the following; it prevents helm-descbinds-mode from being triggered in the first place.

(defun dotspacemacs/user-config ()
  ;; helm-descbinds-mode is activated by being on the helm-mode-hook. However,
  ;; when activated, helm-descbinds-mode disables which-key-mode. So, adjust the
  ;; hook to avoid activating it. See
  ;; https://github.com/syl20bnr/spacemacs/issues/16276
  (remove-hook 'helm-mode-hook 'helm-descbinds-mode)
)

Calling helm-descbinds is still a safe thing to do (e.g., with SPC ?), but if you were to explicitly activate the helm-descbinds-mode, then it would turn off which-key again.

The downside of this fix is that firing C-h in the middle of a long key sequence will no longer trigger helm-descbinds, but to my taste that is easier to swallow than losing which-key entirely.

[davidpiano]

I think I understand more clearly now, thanks to you last two posters.

Am I being short-sighted or unaware when I say I don't think the use of which-key was broken and I therefore wish it hadn't been fixed? (Or at least not been fixed by breaking it worse)

[dankessler]

Am I being short-sighted or unaware when I say I don't think the use of which-key was broken and I therefore wish it hadn't been fixed? (Or at least not been fixed by breaking it worse)

I share your view that in this instance, the "cure" (activation of helm-descbinds-mode causing it to actively disable which-key-mode) is worse than the "disease" (which-key's timer causing C-h to get rebound to paging commands rather than letting it go through to helm-descbinds).

I imagine that this "fix" was prompted by some user who was trying to trigger helm-descbinds with C-h and was frustrated when it didn't give the expected result unless they did it fast enough to beat which-key.

Personally, I was perfectly happy with the old behavior. Indeed, it seems like which-key was designed to allow for using both by letting C-h h or C-h C-h trigger what would usually be behind C-h, so if you struck C-h but were beat by the timer, all you had to do was hit it again.

Unfortunately, disabling which-key now seems fairly baked-in to helm-descbinds, and so working around that is kind of tricky. This is clearly a deliberate decision by the helm-descbinds maintainer. The most graceful way I can think of to get this functionality p back would be a PR to helm-descbinds that exposes a customization option that specifies whether helm-descbinds-mode should disable which-key-mode. That could default to "yes disable it" to reflect the developer's opinion, but it'd enable users that want the old behavior to resurrect it, and moreover this configuration could be baked into spacemacs, too.

UPDATE: I've asked the maintainer of helm-descbinds if they would be receptive to such a PR.

[davidpiano]

This "baked-in" aspect appears political to me. So I will wait until the politics blows over and ordinary humans have figured out how to circumvent the politics and do something reasonable instead.

[dankessler]

Above, @James-Hanson noted:

Specifically, , is not working in LaTeX mode. Also, when I do SPC m-, nothing happens and I get the message SPC m- which-key: There are no keys to show in the messages buffer.

I think this may be a separate (perhaps unrelated) issue that I've also just noticed.

UPDATE: This is indeed an issue, but It has nothing to do with which-key or helm-descbinds so I've opened #16282 to track it.

[dankessler]

helm-descbinds now exposes a configurable option that restores the old behavior. Thanks @davidpiano for making the case for using helm-descbinds and which-key side-by-side! I'll open a PR now so that spacemacs will use this new option

[johnnywalker]

@dankessler Sorry for the slow reply, but thanks for posting the correct workaround. Now that a workaround is no longer needed, I noticed that a previous statement was requiring 'helm-ag as part of a rg workaround. I overlooked that previously and resorted to using eval-after-load. 😄

Thanks everyone for getting this sorted!

[fred-apex-ai]

just ran into this issue. For the record, this worked for me to fix it.

cd ~/.emacs.d
git pull
emacs

Optionally check that the commit mentioned above is contained:

git log --grep="which-key"

commit 58b34a8ea0152e7322b009c9686c6dbecd719e81
Author: Dan Kessler <kesslerd@umich.edu>
Date:   Fri Feb 16 19:40:23 2024 -0800

    ask helm-descbinds not to disable which-key