`vertico` Configuration

[asahnow]

I have a couple questions about your vertico configuration. I played around with it in my own config but ran into some oddities/problems that persisted even when just pasting it into emacs -Q.

1. If window-height is set to 13 and I have more candidates than that, the space where the mode-line once was is still there at the bottom, taking up space that could otherwise show another candidate. Looking at one of your screenshots, it appears to be there as well. Is there any chance you know how to make better use of that space?
2. The resize-mini-windows variäble is not affecting anything. vertico’s buffer opens without regard for the number of candidates, using, apparently, the aforementioned window-height value, and simply keeps that height even when there are more or fewer candidates (traversing through C-x C-f, for example). Digging through vertico’s source, there’s a vertico-resize which seemed like it could be useful but setting it didn’t appear to fix anything. I’d like to set a maximum number of candidates to show (8 – 10) and ensure the vertico buffer never grows past that height but shrinks as much as possible (down to one line) just like vertico usually does when on the bottom.

Any input on these points would be much appreciäted :)

Thanks!

[mclearc]

1. If [`window-height`](https://github.com/Lambda-Emacs/lambda-emacs/blob/289559a57eb194ba785cd3d58b00db1d7b3ae8c5/lambda-library/lambda-setup/lem-setup-completion.el#L120) is set to `13` and I have more candidates than that, the space where the mode-line once was is still there at the bottom, taking up space that could otherwise show another candidate. Looking at one of your screenshots, it appears to be there as well. Is there any chance you know how to make better use of that space?

Previously there were issues with the last candidate being hidden at the bottom when scrolling. I think there was a bug in vertico and to avoid this Daniel added some padding to the display. Perhaps you could look into vertico-buffer and the display-buffer-in-side-window function further to see if there is some way to tweak the settings to your liking.

2. The [`resize-mini-windows`](https://github.com/Lambda-Emacs/lambda-emacs/blob/289559a57eb194ba785cd3d58b00db1d7b3ae8c5/lambda-library/lambda-setup/lem-setup-completion.el#L148) variäble is not affecting anything. 

This is because vertico is using vertico-buffer, which does not use the mini-buffer.

I’d like to set a maximum number of candidates to show (8 – 10) and ensure the vertico buffer never grows past that height but shrinks as much as possible (down to one line) just like vertico usually does when on the bottom.

I don't believe this kind of resizing is possible (at least not without more code) for the display-buffer-in-side-window. But I could be wrong. I find the resizing distracting. You might look into using emacs-mini-frame or posframe if you want resizing and display somewhere other than the bottom.

[asahnow]

Previously there were issues with the last candidate being hidden at the bottom when scrolling. I think there was a bug in vertico and to avoid this Daniel added some padding to the display. Perhaps you could look into vertico-buffer and the display-buffer-in-side-window function further to see if there is some way to tweak the settings to your liking.

Ah OK, thanks for the context. I may look into that sometime.

This is because vertico is using vertico-buffer, which does not use the mini-buffer.

That makes sense. I was thinking that it would just start treating whatever buffer it spawned in as the minibuffer but I guess not.

I don't believe this kind of resizing is possible (at least not without more code) for the display-buffer-in-side-window. But I could be wrong. I find the resizing distracting. You might look into using emacs-mini-frame or posframe if you want resizing and display somewhere other than the bottom.

I’ve actually been using vertico-posframe for quite a while—probably since it came out—but it just still feels buggy. No matter how much I customize it, it still frustrates me. I’ll live with the set height for now.

Thanks!

[mclearc]

Actually you might try this and see what you think.

EDIT: maybe it warrants a bit more explanation -- note that the window size at the end lessens the vertico-count value by 1 from Daniel's original (and I still remove the header-line). This narrows the empty space. A count of 0 removes the empty space but obscures the final candidate.

(defun vertico-buffer--setup ()
    "Setup buffer display."
    (add-hook 'pre-redisplay-functions 'vertico-buffer--redisplay nil 'local)
    (let* ((action vertico-buffer-display-action) tmp win
           (_ (unwind-protect
                  (progn
                    (setq tmp (generate-new-buffer "*vertico*")
                          ;; Temporarily select the original window such
                          ;; that `display-buffer-same-window' works.
                          win (with-minibuffer-selected-window (display-buffer tmp action)))
                    (set-window-buffer win (current-buffer)))
                (kill-buffer tmp)))
           (sym (make-symbol "vertico-buffer--destroy"))
           (depth (recursion-depth))
           (now (window-parameter win 'no-other-window))
           (ndow (window-parameter win 'no-delete-other-windows)))
      (fset sym (lambda ()
                  (when (= depth (recursion-depth))
                    (with-selected-window (active-minibuffer-window)
                      (when (window-live-p win)
                        (set-window-parameter win 'no-other-window now)
                        (set-window-parameter win 'no-delete-other-windows ndow))
                      (when vertico-buffer-hide-prompt
                        (set-window-vscroll nil 0))
                      (remove-hook 'minibuffer-exit-hook sym)))))
      ;; NOTE: We cannot use a buffer-local minibuffer-exit-hook here.
      ;; The hook will not be called when abnormally exiting the minibuffer
      ;; from another buffer via `keyboard-escape-quit'.
      (add-hook 'minibuffer-exit-hook sym)
      (set-window-parameter win 'no-other-window t)
      (set-window-parameter win 'no-delete-other-windows t)
      (overlay-put vertico--candidates-ov 'window win)
      (when (and vertico-buffer-hide-prompt vertico--count-ov)
        (overlay-put vertico--count-ov 'window win))
      (setq-local show-trailing-whitespace nil
                  truncate-lines t
                  face-remapping-alist
                  (copy-tree `((mode-line-inactive mode-line)
                               ,@face-remapping-alist))
                  header-line-format nil
                  mode-line-format nil
                  cursor-in-non-selected-windows 'box
                  vertico-count (- (/ (window-pixel-height win)
                                      (default-line-height)) 1))))

[mclearc]

Here's a screenshot. It doesn't resize, but at least you don't have the gap. I had actually never even noticed it until you pointed it out -- then I couldn't unsee it! :)

[asahnow]

Actually you might try this and see what you think.

That does it; that’s great!

I had actually never even noticed it until you pointed it out -- then I couldn't unsee it! :)

Sorry :)

FWIW, I found what looks like vertico-buffer-mode ignoring the resize function here. I removed that line and the buffer actually starts to grow and shrink by (very) small amounts. I think this may be on the right track though, as its size wasn’t even changing at all before.