Optionally shrink to match candidate list length/height

[protesilaos]

Hello again Daniel! This is more of a stylistic point, but what do you think about reducing the height of the minibuffer when there is empty space? In this scenario I would expect the minibuffer to contract:

[manuel-uberti]

I am not seeing this behaviour:

Although this is from my configuration, not with emacs -Q.

EDIT: scratch that, I am seeing it too with more than two buffers open.

[minad]

Yes, I am overwriting the variable (setq-local resize-mini-windows 'grow-only), since it must not be nil in order for the display to work. What I could do is to overwrite it only when it is nil and keep it otherwise. If you set the variable to t in your config, it should then grow and shrink as you expect. Does that sound like a good solution?

[protesilaos]

If you set the variable to t in your config, it should then grow and shrink as you expect. Does that sound like a good solution?

Yes, that sounds good, though it did not work in my case. The screenshot I shared originally had it to t. Same here:

[manuel-uberti]

Same for me here with (setq-default resize-mini-windows t).

[minad]

Yes, that sounds good, though it did not work in my case. The screenshot I shared originally had it to t. Same here:

This sounds like an Emacs 28 bug then, you are both using Emacs 28, right? There have been some recent changes in Emacs 28 on how it resizes the minibuffer and Selectrum has also been affected by that.

[manuel-uberti]

Yes, I am on Emacs 28, and I did chat with @clemera about this problem on Selectrum here.

[minad]

@manuel-uberti Yes, I've seen that discussion but didn't fully read it. Note that Vertico does not perform its own resizing, it simply relies on Emacs doing the right thing. For this reason I am also not setting truncate-lines to t since this would break the resizing on Emacs 27.

[manuel-uberti]

FTR, even with truncate-lines set to t (and resize-mini-windows set to t at the same time) the problem remains. I guess something is changed on Emacs master then.

[minad]

If you have time I would appreciate if you report a bug or take a look if such a bug already exists. So to be precise, the minibuffer is grown correctly if you set 'grow-only? And if you set the variable to t it also grows but does not shrink as it should? If you set it to nil, the variable is still overwritten locally by Vertico with 'grow-only.

[minad]

Maybe we can create a minimal reproducible example. This works for me on 27.1.

(defvar-local test-resize-ov nil)

(defun test-resize ()
  (if (overlay-get test-resize-ov 'after-string)
      (overlay-put test-resize-ov 'after-string nil)
    (overlay-put test-resize-ov 'after-string "Multiple Lines 1\nMultiple Lines 2\nMultiple Lines 3")))

(minibuffer-with-setup-hook
    (lambda ()
      (setq-local resize-mini-windows t)
      (setq test-resize-ov (make-overlay (point-max) (point-max) nil t t))
      (add-hook #'post-command-hook #'test-resize nil t))
  (read-from-minibuffer "Test: "))

[manuel-uberti]

These are the results with different values for resize-mini-windows:

• 'grow-only: the minibuffer is grown as expected but doesn't shrink as it should
• t: the minibuffer is grown as expected but doesn't shrink as it should
• nil: the value for resize-mini-windows is locally set by vertico (i.e., Local in buffer *Minibuf-1*; global value is nil), but the behavior is as reported for 'grow-only and t

Let me try with your example.

[manuel-uberti]

With your code in emacs -Q, I get this.

How can I test the shrinking, though?

[minad]

It is a toggler, just press a few keys "xxxxx"

[manuel-uberti]

Right, here we go: