which-key-side-window truncates entries

[triklsbg]

Can't see C-c C-t for example. Thanks

[triklsbg]

my customization in init.el:

  (use-package which-key
    :ensure t
    :config (progn
            (push '((nil . "projectile") . (nil . "proj")) which-key-replacement-alist)
            (setq which-key-idle-delay 0.4) ; default is 1.0
            (setq which-key-side-window-max-width 0.9) ; default 0.333
            (setq which-key-side-window-max-height 1)  ; default 0.5
            (which-key-mode)
            (which-key-setup-side-window-right))
  :diminish which-key-mode
  )

[triklsbg]

accidentally closed

[justbur]

It seems that something is off with the window height calculation. This is simply done as frame height minus the height of the minibuffer. My guess would be that frame-height is wrong for some reason. This looks like a terminal. Is that right?

[triklsbg]

The screenshot is from a gui. I reset which-key-side-window-max-height to .25 (=the default) but nothing changed.

[triklsbg]

I did not intentionally changed the mode-line. doom-modeline is installed and activated.

[justbur]

This is going to be tricky for me to figure out, because I can't reproduce it. which-key-side-window-max-height only affects the height of the window when its on the bottom, so that won't change anything.

When you have the frame sized in such a way to cause the problem (like with your screen shot above) can you execute the following (maybe using M-:) and paste the result from the messages buffer here?

(message "(frame-height) -> %s\n(frame-char-height) -> %s\n(frame-pixel-height) -> %s"
         (frame-height) (frame-char-height) (frame-pixel-height))

[triklsbg]

The given values seem plausible to me. Perhaps it helps to number the which-key entries to get an idea of whats going on.

[justbur]

That looks fine to me. I'm still not sure what is going on. I added some more debugging output in c87b0ce. If you set which-key--debug-buffer-name to some string, you should get debugging information in a buffer with that name. In other words, do something like

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

And then check the contents of the *wk-debug* buffer. If you could paste the information from that buffer corresponding to a time that the problem occurs, I might see what the issue is (or add some more information to the output).

Thanks for your help on this.

[matsievskiysv]

There's a similar issue with bottom side-window:

[mmarshall540]

I'm seeing the same thing as triklsbg. Just switched from MELPA to 9f64733, but result is the same.

Here's my output in the *wk-debug* buffer:

Frame height: 61
Minibuffer height: 1
Max dimensions: (59,205)
Available for bindings: (58,205)
Actual lines: 58

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

If it's any help to know, my Emacs was compiled from the then-current master branch about a week ago, and I'm using a widescreen monitor at 2560x1080.

But it doesn't seem to matter if the window is maximized, full-screen, or floating. It always cuts off 2 lines at the bottom if I use (which-key-setup-side-window-right-bottom).

[alwyn]

I see the same as @matsievskiysv when I set max height to 1.

In my case I use bottom and have changed my doom-font to size 18. This causes the which-key window to truncate the entries. Easy to see when pressing SPC w.

The above screenshot is at the default 0.25 max height setting.

UPDATE: I can confirm that at least in my case this happens when running emacsclient. Standalone it works fine.

[ilohmar]

This is not quite the same, but probably related to a similar bug that I've been seeing. If there are other side windows besides the which-key one, then depending on the value of window-sides-vertical, the which-key side window extends to the full height/width, or only to the part next to the main window (ie, it is "blocked" by other side windows on an orthogonal side).

This issue can be amended by replacing the following two functions:

(defun which-key--width-or-percentage-to-width (width-or-percentage)
  "Return window total width.
If WIDTH-OR-PERCENTAGE is a whole number, return it unchanged.  Otherwise, it
should be a percentage (a number between 0 and 1) out of the frame's width.
More precisely, it should be a percentage out of the frame's root window's
total width."
  (if (wholenump width-or-percentage)
      width-or-percentage
    (round (* width-or-percentage
              (window-total-width
               (if window-sides-vertical
                   (window-main-window)
                 (frame-root-window)))))))

(defun which-key--height-or-percentage-to-height (height-or-percentage)
  "Return window total height.
If HEIGHT-OR-PERCENTAGE is a whole number, return it unchanged.  Otherwise, it
should be a percentage (a number between 0 and 1) out of the frame's height.
More precisely, it should be a percentage out of the frame's root window's
total height."
  (if (wholenump height-or-percentage)
      height-or-percentage
    (round (* height-or-percentage
              (window-total-height
               (if window-sides-vertical
                   (frame-root-window)
                 (window-main-window)))))))

Do these changes help? I have not tried to understand all width/height calculations, but I am confident that the above changes are one step closer to getting them right --- even if they might not help with the original issue.