Skip to content
This repository has been archived by the owner on Jun 25, 2024. It is now read-only.

Which-key side-window cuts off some rows #369

Open
deen1 opened this issue Apr 4, 2024 · 6 comments
Open

Which-key side-window cuts off some rows #369

deen1 opened this issue Apr 4, 2024 · 6 comments

Comments

@deen1
Copy link

deen1 commented Apr 4, 2024

See the images below; the Which-key information for the C-x prefix doesn't show the full list of commands after C-x i, and paging via C-h n just jumps to C-x p rather than showing the info related to C-x j, C-x k etc.

I've tried:

  • Changing which-key-side-window-location to bottom rather than
    right, and also using the minibuffer
  • Increasing which-key-side-window-max-width=/-height=,
  • Changing the heights of different Which-key faces

The only change that makes a difference is changing which-key-popup-type to 'frame, but that's not the most ideal option for my workflow.

Also, doing (setq which-key-allow-imprecise-window-fit nil) makes a difference when the side-window is at the bottom, but not on the right hand side of the frame.

Is there a consistent fix for this? Should I try writing my own custom-show-popup-function?

https://github.com/justbur/emacs-which-key/assets/1893566/22f6aa35-b8b0-4a8c-868f-6208eb0a06ea
https://github.com/justbur/emacs-which-key/assets/1893566/e800771b-7bd3-4a35-b81d-3fc951ce274e

@justbur
Copy link
Owner

justbur commented Apr 9, 2024

Can you reproduce this by starting emacs without your config (emacs -Q) and loading a basic configuration for which-key like

(require 'which-key)
(which-key-setup-side-window-right)
(which-key-mode)

?

@deen1
Copy link
Author

deen1 commented Apr 12, 2024

My apologies for the slow response.

I tried loading which-key via emacs -Q, with (which-key-setup-side-window-right). The paging display for C-x now fits within the side-window, without any cutting off (see screenshots below).

I then enabled my usual Emacs theme (from the package monokai-theme), and things seemed to be fine.

I was able to reproduce the issue when I made the default frame face larger (to be compatible with my display and eye comfort):

(add-to-list 'default-frame-alist '(font . "Ubuntu Mono-14:antialising=True") )

So it seems to me that one solution for this would be to make the default which-key face smaller, but I haven't been able to do that in a uniform way – i.e. some of the faces become smaller but others don't, so that the completion list is still obscured/cut off, but at a different location to the previous situation.

2024-04-12-150322_327x944_scrot

2024-04-12-150339_491x934_scrot

@justbur
Copy link
Owner

justbur commented Apr 13, 2024

First off, the intention is for the window to scale appropriately if the font is larger. I just checked that mine does even for larger font sizes than the one you're using.

From the pictures above, it seems like the character widths are not being handled properly. Can you try the following? First,

(setq which-key--debug-buffer-name "wk-debug")

That will dump out some of the calculations to the buffer "wk-debug". I'd like to see what it spits out for one of the problematic cases, preferably like you have here starting from emacs -Q. If possible it would be nice to have a screenshot that corresponds to the data from "wk-debug". Does that make sense?

@deen1
Copy link
Author

deen1 commented Apr 14, 2024

OK, I tried the following: after loading which-key via straight in
emacs -Q,

(require 'which-key)
(which-key-setup-side-window-right)
(which-key-mode)
(add-to-list 'default-frame-alist '(font . "Ubuntu Mono-14:antialising=True") )
(setq which-key--debug-buffer-name "wk-debug")

(Note: this time I didn't load a theme, I just changed the default frame face.)

Opening a new frame (so that the larger font is applied), and hitting C-x produces the following output in wk-debug:

Frame height: 45
Minibuffer height: 1
Max dimensions: (43,56)
Available for bindings: (42,56)
Actual lines: 43

On prefix "C-x" which-key took 113 ms.

Below is the associated screenshot of the first page for the C-x commands:

2024-04-14-151808_332x938_scrot

I also tried C-h to see if there is any difference:

Frame height: 45
Minibuffer height: 1
Max dimensions: (43,56)
Available for bindings: (42,56)
Actual lines: 43

On prefix "C-h" which-key took 43 ms.

I hadn't implemented any special paging for C-h so I couldn't see the remaining options, but the list of commands doesn't look as though it is cut off in the way C-x is:

2024-04-14-155332_344x930_scrot

@justbur
Copy link
Owner

justbur commented Apr 23, 2024

Sorry, I meant for you to update which-key first because I added some more information to the debug output. Do you mind doing what you did again after updating which-key?

@deen1
Copy link
Author

deen1 commented Apr 26, 2024

I tried it again after updating – it's still version 3.6.0 but it has the new =which-key--debug-message= changes.

The problem remains, here is the output to the wk-debug buffer:

Frame height: 45
Frame pixel width: 1920
Frame char width: 10
Frame width: 192
Which-key initial width: 64
Which-key adjusted width: 59
Minibuffer height: 1
Max dimensions: (43, 56)
Available for bindings: (42, 56)
Popup type info: (side-window, right, 0.333)
Computed page widths: (33 35 32)
Actual lines: 43

Allow imprecise fit: nil
Display window alist: ((window-width . which-key--fit-buffer-to-window-horizontally) (window-height lambda (w) (fit-window-to-buffer w nil 1)) (side . right) (slot . 0))

On prefix "C-x" which-key took 94 ms.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants