Emacsclient (in daemon mode) doesn't start after adding prelude-helm-everywhere

[aviav]

Expected behavior

After I uncomment prelude-helm-everywhere, start Emacs in daemon mode, and enter emacsclient -t on the terminal, Emacs Prelude starts.

Actual behavior

Entering emacsclient -t just leads to an empty shell prompt, without persistent output on the terminal. Doing emacsclient -t 2> tmp-1, I see the following error in the file: *ERROR*: ‘which-key-mode’ can’t be used with ‘helm-descbinds-mode’.

This is fixed by commenting out in .emacs.d/core/prelude-ui.el

(if (daemonp)                                                                                                                                                                                                                          
    (add-hook 'server-after-make-frame-hook 'which-key-mode)                                                                                                                                                                           
  (which-key-mode +1))

and then killall emacs. After then restarting emacs in daemon mode I can open a client on the terminal as expected.

Note that starting emacs without daemon mode with emacs works without any issue for me, in any case.

There seem to have been changes related to the error in helm-descbinds four months ago. The issue first occurred for me after I updated Prelude today, which I don't do that often.

Steps to reproduce the problem

• Backup and delete pre-existing .emacs.d
• Install Emacs Prelude using curl -L https://git.io/epre | sh
• Using a different editor, uncomment (require 'prelude-helm-everywhere) in .emacs.d/personal/prelude-modules.el
• Run /usr/bin/emacs --daemon
• Run emacsclient -t

Environment & Version information

Emacs version

GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu)

Operating system

Arch Linux

[xmo-odoo]

spacemacs apparently has workarounds to try and handle this but in prelude this causes startup issues and odd unresponsive commands e.g. when using magit and emacsclient as git's EDITOR emacs seems to terminate the client causing git and magit to desync, it also prevents buffers invoked from emacsclient (either new ones or revisiting of files open in existing buffers) to rise to the top, leading to a very strange and frustrating experience.

For SEO purposes, the specific error I got is

which-key-mode can't be used with helm-descbinds-mode

in the magit commands buffer, which led me to the same solution of disabling which-key before finding this issue.

The issue first occurred for me after I updated Prelude today, which I don't do that often.

Similar story here, I replaced my laptop, redid my setup, and updated prelude while at it, took me some time to figure out this issue as I initially chalked the odd behaviours up to trying out flatpak emacs (turns out this was not its fault)

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed soon if no further activity occurs. Thank you for your contribution and understanding!

[holocronweaver]

Still a problem in Emacs 30.1, latest prelude.

[ryukinix]

I am still able to reproduce this issue. Previously, about a year ago, I implemented a workaround using defadvice to bypass the helm-descbinds upgrade and reverted to an earlier version that did not have this bug before 202402XX, and the previous v ersion is from 20190501.935 . I tested the solution of commenting out the automatic injection of the which-key-mode hook, as suggested by the author of this issue. It works, but which-key-mode is gone, as expected. It would be preferable if this issue could be resolved without the need to debug or modify the internals of Prelude. Maintaining a stable terminal session using daemon is crucial for my workflow.

Related discussion: https://www.reddit.com/r/emacs/comments/1amdcd0/how_do_i_figure_out_which_updated_package_breaks/

Since this upgrade, it appears that helm-descbinds and which-key-mode have become incompatible. helm-descbinds add a defadvice over which-key-mode that raise a error when is called here . In theory, defining this variable helm-descbinds-disable-which-key to nil would be enough to get rid of this effect, however it didn't work with me. ref

One potential solution could be to create a custom variable to control the auto-enabling of which-key-mode in such a way that the helm-everywhere Prelude module disables it. The challenge with this approach is the loading order, as prelude-ui is loaded before the helm-everywhere module.

Alternatively, instead of commenting out the code, we could ignore errors when attempting to enable which-key-mode (an ugly solution, but it prevents the entire terminal session from crashing).

(if (daemonp)
    (add-hook 'server-after-make-frame-hook
              (lambda ()
                (ignore-errors (which-key-mode +1))))
  (which-key-mode +1))

[ryukinix]

I organized my personal fix in my local repository and opened a PR: https://github.com/bbatsov/prelude/pull/1435

It's not perfect, but at least avoid the crash. The which-key-mode is still disabled using helm-everywhere since they are incompatible.