Selectrum: Selectrum minibuffer is not resized on emacs -Q

[minad]

This one is a bit odd - Selectrum does not resize when using a minimal configuration in emacs -Q. The minibuffer remains a single line, when doing M-x for example. I am not observing this with my real configuration only with emacs -Q on 27.1.

~ elisp
(package-initialize)
(require 'selectrum)
(selectrum-mode)
(setq completion-styles '(substring))
~

[clemera]

Hm, not sure what is happening on your side I can't reproduce it.

[clemera]

Could you try without package-initialize?

[minad]

Also happens with:

~ elisp
(load "~/selectrum/selectrum.el")
(selectrum-mode)
~

Are you also using 27.1?

EDIT: I used e51e2cf2a9498eab8db3cf864e7c75b50138f957 on Linux Emacs 27.1.

[clemera]

Yes, Emacs 27.1 using e51e2cf it resizes for me when starting like this and doing M-x:

emacs -Q -l selectrum.el -f selectrum-mode --eval "(setq completion-styles '(substring))"

[minad]

As soon as I press any key, Selectrum resizes.

[minad]

~WTF - emacs -Q -l selectrum.el -f selectrum-mode --eval "(setq completion-styles '(substring))" works for me.~

EDIT: ~Not true, I made a mistake and started Emacs 26.~ It also happens on Emacs 26, the Debian version.

EDIT2: So after carefully checking again, it happens always for me with emacs -Q. On both 26 and 27.1. When executing the snippet I pasted above and also when using the command line you pasted.

[clemera]

It works without problems here, this shouldn't depend on anything else than Emacs so I don't have a clue why you observe this behaviour.

[clemera]

To make sure it is not my key repeat settings or anything I also tried:

emacs -Q -l selectrum.el -f selectrum-mode --eval "(call-interactively 'execute-extended-command)"

which directly drops me into completion.

[minad]

Does not work for me, on neither 27.1 nor 26.1.

[minad]

It seems to be related to some X resources configuration.

Does not work:
~
emacs -q --no-site-file --no-site-lisp --no-splash --no-x-resources -l selectrum.el -f selectrum-mode --eval "(call-interactively 'execute-extended-command)"
~

Works:
~
emacs -q --no-site-file --no-site-lisp --no-splash -l selectrum.el -f selectrum-mode --eval "(call-interactively 'execute-extended-command)"
~

EDIT: After executing xrdb -remove the problem occurs in both cases, this means if the x-resources are missing the problem occurs.

[clemera]

Both examples work on my side, also tried with an old copy of Emacs 26.3 which works, too so it has to be something else.

[minad]

It is super weird, it only works when I have the following in my Xresources:

~
emacs.menuBar: off
emacs.toolBar: off
emacs.horizontalScrollBars: off
emacs.verticalScrollBars: off
emacs.fullscreen: maximized
~

This looks like some bug with the size computation. As if some of the values reported by Emacs are 0 for the font or frame size and then the minibuffer window size is computed wrongly.

[clemera]

I have no Emacs settings in my Xresources, really strange.

[clemera]

The function that gets used is selectrum--set-window-height with no height passed if that helps you debugging it.

[minad]

I tested with this:

~ elisp
(defun selectrum--set-window-height (window &optional height)
"Set window height of WINDOW to HEIGHT pixel.
If HEIGHT is not given WINDOW will be updated to fit its content
vertically."
(message "set-window-height %S %S" window height)
(let ((dheight (or height (cdr (window-text-pixel-size window))))
(wheight (window-pixel-height window))
(window-resize-pixelwise t))
(message "dheight=%S wheight=%S %S" dheight wheight (window-text-pixel-size window))
(window-resize
window (- dheight wheight) nil nil 'pixelwise)))
~

It reports

~
set-window-height # nil
dheight=87 wheight=29 (1078 . 87)
~

EDIT: And with the xresources, where everything works for me:

~
set-window-height # nil
dheight=105 wheight=35 (1216 . 105)
~

EDIT2: When starting emacs -Q -l selectrum.el -f selectrum-mode and then going into fullscreen mode it works too. This sounds more like an Emacs bug now. I hope the pgtk frontend appears soon. But maybe Selectrum could do the resizing in a different more reliable way, I don't know?

EDIT3: Ivy does not have the problem, when starting emacs -Q -l ivy-faces.el -l ivy-overlay.el -l colir.el -l ivy.el -f ivy-mode.

[purcell]

I'm getting what might be the same behaviour in gccemacs (28) on macOS. Straight after startup, most - but not all - minibuffer commands with completion show only one result at a time in the minibuffer, though there are more results and they can be scrolled with C-n etc.

execute-extended-command, describe-function and consult-buffer are commands which show only one result. switch-to-buffer, strangely, shows three. Meanwhile find-file works completely normally, showing 10 results. This is in a GUI frame, but the result is the same in a terminal frame opened via emacsclient.

Weird!

[purcell]

This appears to be because when selectrum-fix-vertical-window-height is off, (selectrum--set-window-height window) is called, and when that function isn't passed a height, it just sets the window to its current height. So in this code path there's nothing that sets a height based on the amount of content in the buffer: selectrum--expand-window-for-content-p looks at window-body-height (the content height) but selectrum--set-window-height just looks at the window's physical size.

[clemera]

selectrum--expand-window-for-content-p looks at window-body-height (the content height) but selectrum--set-window-height just looks at the window's physical size.

Hm, it also looks at window-text-pixel-size so the content should be taken into account I think. For some reason I can't reproduce the problem at all (Emacs 27.1/Xorg).

[purcell]

Hm, it also looks at window-text-pixel-size so the content should be taken into account I think.

Yes, true, for some reason I was mis-remembering that that was the height of the visible text. In any case, I just updated to the latest selectrum/consult/embark and everything seems to be working again. :-/

[purcell]

In any case, I just updated to the latest selectrum/consult/embark and everything seems to be working again. :-/

Ah no, still happens for some commands, e.g. consult-buffer. Very mysterious.

[purcell]

Enabling selectrum-fix-vertical-window-height does fix this btw, but it feels like it shouldn't be necessary.

[clemera]

@purcell Does this only happen when there are fewer candidates than selectrum-max-window-height? Because in that case it is intended that the mini window only expands up to the needed height. But if you don't like that behavior you can set selectrum-fix-vertical-window-height as you discovered already.

[purcell]

@purcell Does this only happen when there are fewer candidates than selectrum-max-window-height?

No, when it happens, there are many further candidates "off-screen".

Because in that case it is intended that the mini window only expands up to the needed height. But if you don't like that behavior you can set selectrum-fix-vertical-window-height as you discovered already.

Yes, that would be my preferred behaviour.

[clemera]

No, when it happens, there are many further candidates "off-screen".

Hm, that is not good, hopefully we can find a reproducible recipe.

Yes, that would be my preferred behaviour.

I did this in the past, too but it can be a bit weird when there are no candidates for example. I finally switched back to the behavior which only expands as much as needed.

[purcell]

I finally switched back to the behavior which only expands as much as needed

Yes, that's what I'm talking about: that's my preference. And I think it's how things are supposed to work with selectrum-fix-vertical-window-height off.

[clemera]

Ah thanks, I misunderstood that, yes this would be how it is supposed to work with the option turned off.

[clemera]

@purcell Maybe window-text-pixel-size does not work correctly on your side for some reason? What happens if you use the following definition in place of the current one:

(defun selectrum--set-window-height (window &optional height)
  "Set window height of WINDOW to HEIGHT pixel.
If HEIGHT is not given WINDOW will be updated to fit its content
vertically."
  (let* ((str (overlay-get selectrum--candidates-overlay 'after-string))
         (lines (1+ (cl-count ?\n str)))
         (dheight (or height
                      (* lines selectrum--line-height)))
         (wheight (window-pixel-height window))
         (window-resize-pixelwise t))
    (window-resize
     window (- dheight wheight) nil nil 'pixelwise)))

[ChrisCochrun]

I've been having the exact same problem as @purcell and just tested your definition of selectrum--set-window-height @clemera. It worked for me. Restores selectrum to having it's full height every time opened.

[minad]

@clemera In my case with emacs -Q on Emacs 27.1, the modified selectrum--set-window-height function from above does not fix the issue unfortunately. However my issue is also not fixed by setting selectrum-fix-vertical-window-height. It seems that @purcell and I are observing two different resizing issues.

[clemera]

@ChrisCochrun Thanks, are you also on Emacs 28 (MacOs) as @purcell? Can anyone check if this problems also exists with Emacs 28 on Xorg?

[clemera]

@minad Thank you, yes it seems it is something different it looks like we need to find a better more reliable way to do the resizing in general.

[clemera]

It seems if we don't set truncate-lines the resizing of the minibuffer is handled automatically (when resize-mini-windows is set) and we don't need to use selectrum--update-window-height at all. For some reason truncating lines prevents the auto resizing.

[minad]

Yes, this fixes the issue on emacs -Q but leads to line breaks.

[clemera]

Yes, ideally we would want to keep the truncation option so that long lines don't wrap around (also there was a final newline that did not belong there, see 48e4e1806cda99df3de2447fc929769307945e38). I opened a bug report for the resizing issues in combination with line truncation.

[ChrisCochrun]

@clemera Yes, I am on Emacs 28 but on Xorg. So it seems consistent across macos and xorg right?

[clemera]

Okay, then it seems like a problem with window-text-pixel-size in Emacs 28. But strange that it only doesn't work for some commands? Maybe this problem was introduced just recently? I will try to add a workaround later, this means on Emacs 28 you won't get the correct height when your candidate lines aren't at normal height but that would still be better than the current problems.

[ChrisCochrun]

I believe it was just introduced recently, I updated my build of Emacs 28 from the AUR just last night and noticed this morning the strange behavior.

[clemera]

@purcell @ChrisCochrun Thankfully the problem in combination with truncate-line should be fixed on current master (commit eef185dfc8) so we should now be able to rely on the auto resizing for Emacs 28 and later. I added a check for the Emacs version in 5c2b184c9adb036bfd71251a060ae8bc9bbceb70, please test with an up to date build if the problem is fixed for you.

[purcell]

Yay!

[clemera]

I haven't actually tested it as I'm not using Emacs 28 yet, but I probably can't resist as soon as the native compile branch gets merged into master :)

[jaor]

i'm experiencing (a form of) this issue when running commands such as
customize-face or helpful-symbol, with an emacs compiled from master
today, and the latest selectrum in melpa. in my case what happens is
that i see a minibuffer with only the top entry in the list, and C-n and
similar have no effect on the display. if i set
selectrum-fix-vertical-window-height, that's honoured.

[clemera]

Users need some time to update their Emacs 28, see 5c2b184c9adb036bfd71251a060ae8bc9bbceb70, for the time being setting selectrum-fix-vertical-window-height is the recommended workaround for now for affected users.