`emacs --daemon` causes which-key popup to have improper vertical size
adql opened this issue · 6 comments
Expected behavior
Normal display of which-key popup when connecting with emacsclient -c to a server started with emacs --daemon.
Actual behavior
The which-key popup has an issue with the vertical size which, apart from making it somewhat smaller, often cuts the bottom line in a way that make it unreadable. Scrolling to the next page doesn't display that line, so it's "lost".
The problem doesn't occur when just running emacs, or when running emacsclient -c to connect to a server that was started with M-x server-start.
On the left is a client connected to a server-start-type server, displaying properly. On the right is a client connected to a daemon. As can be seen, there's a line beneath that of the d and r keys which is barely visible (should be for e and s). Scrolling with C-h n goes directly to the f and t line, so two key bindings are not displayed (on a full screen it would be four on my display).
Testing on a vanilla Emacs with only which-key installed doesn't reproduce the problem, which suggests that it's in Prelude.
Steps to reproduce the problem
- Start emacs daemon:
emacs --daemon - Connect to the daemon:
emacsclient -c - Press a prefix key such as
C-corC-x
Environment & Version information
Emacs version
27.2
Operating system
Manjaro Linux (rolling) with i3 WM.
There was a similar issue opened for which-key years ago, but it seems to be related to golden-ratio which is not used in Prelude, and not related to daemon.
I haven't observed this issue, but if you find a solution do let me know. Likely it's an issue with which-key, that's unrelated to Prelude.
@bbatsov true, no idea how I had missed that one, since I clearly remember testing it on vanilla Emacs and checking the issues on which-key's repo... sorry!
Anyway, I've made a couple of tests and (require 'which-key) at initialization is enough to reproduce the bug, even when holding enabling the mode until a client is started. It's easily solvable with a dirty-ish workaround until the bug is fixed upstream, I'll submit a pull request soon.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!
elats
The recent commit adds a workaround which can be removed when the upstream issue is resolved.