Selectrum: Resizing issue with long candidates (Emacs 28 specific)

[aaronjensen]

I have no idea where the issue is, but since you all are so helpful here I'm opening it here for now 😄

This one is weird because on some days it works every time. Usually after I install a new version of emacs, it stops working. I've played with various mini-frame settings to no avail. Any hints on debugging and/or can anyone else repro?

Thanks!

[clemera]

Have you looked at the suggestions in the wiki?

[aaronjensen]

Yes, and I'm in Emacs 28 (just compiled today)

[clemera]

Sorry, I don't know how to help with that for now then. Is this only with consult-buffer?

[aaronjensen]

Yes, that's all I've seen it with.

[aaronjensen]

Actually, I can reproduce it even with mini-frame disabled, so that's interesting. I'll dig in a bit.

[aaronjensen]

Here's a repro:

Make sure your window is narrow enough that the x's below will truncate

(package-initialize)
(recentf-mode)
(setq recentf-list '("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"))
(require 'consult)
(require 'selectrum)
(selectrum-mode)
(setq completion-styles '(substring))

Then M-x consult-buffer

It appears that if there is truncation, resizing doesn't work.

[clemera]

Resizing problems with Emacs 28 have been reported before, but in #520 it appeared they are fixed. It might be that something changed upstream again or long candidates with truncation weren't tested before. Maybe @mohkale and @manuel-uberti can try to reproduce this? In theory Emacs 28 should automatically handle the resizing so the manual resize we do shouldn't be needed anymore.

[manuel-uberti]

I followed the recipe from emacs -Q and I got this when doing M-x consult-buffer:

[clemera]

@manuel-uberti Thank you! It appears the problem is only with miniframe-mode then.

[aaronjensen]

@manuel-uberti you need to reduce the width of your window or add more x’s. As I mentioned it need to truncate.

I can repro without mini frame.

[clemera]

@aaronjensen Could you try to eval (fset #'selectrum--update-window-height #'ignore) and how that affects the resizing behavior? Though as the issue is also with mini-frame this shouldn't fix it.

[aaronjensen]

@clemera no change, still broken.

[clemera]

@aaronjensen Okay thanks, you could check with vertico by @minad which doesn't truncate lines. If it works there it should be an issue in Emacs 28 with line truncation in minibuffer which for some reason only happens with consult-buffer.

[manuel-uberti]

@manuel-uberti you need to reduce the width of your window or add more x’s. As I mentioned it need to truncate.

I can repro without mini frame.

This is what I have without maximizing the window:

[aaronjensen]

I couldn't figure out where the code is that draws those headers. I wonder if it somehow has something to do w/ that. I can't reproduce it with find-files when there's a file name long enough to truncate. I'll check w/ vertico when I can.

[minad]

Okay thanks, you could check with vertico by @minad which doesn't truncate lines. If it works there it should be an issue in Emacs 28 with line truncation in minibuffer which for some reason only happens with consult-buffer.

@clemera Not anymore. Vertico uses almost the same window resizing approach as Selectrum now.

[aaronjensen]

Hm, @minad can you reproduce this with vertico? I haven't had a chance to try it. Also, could you point me to the code in consult that draws the group headers with the horizontal line? I'm curious if that's what's confusing the size calculation somehow.

[minad]

@aaronjensen Is this an Emacs 28 issue? I am still on 27. But you can try Vertico quickly yourself. 1. (selectrum-mode -1), (vertico-mode 1) and everything should behave mostly the same. But Vertico probably has the same issue, there is not much magic here. It is probably an 28 bug.

[aaronjensen]

It does appear to be an Emacs 28 issue. I'll bisect and report.

[aaronjensen]

@minad could you link to the line in consult that draws the horizontal separators w/ the group names in consult-buffer please?

[minad]

https://github.com/raxod502/selectrum/blob/2009e5490034855d151b8ac0fa5af73c61c6e74f/selectrum.el#L917-L923

Consult specifies a "title function" which is then used to build the candidates groups:

https://github.com/minad/consult/blob/7cfe3bac6dccd44427f0d4276e7ec815f57b797a/consult.el#L1878

Group function:

https://github.com/minad/consult/blob/7cfe3bac6dccd44427f0d4276e7ec815f57b797a/consult.el#L1610-L1619

https://github.com/minad/consult/blob/7cfe3bac6dccd44427f0d4276e7ec815f57b797a/consult.el#L1686-L1687

[aaronjensen]

https://github.com/emacs-mirror/emacs/commit/56c42bd28d9be400e37e122b7abebcd980ea0e8b is the commit that caused the issue. I've reported it upstream.

[aaronjensen]

Unfortunately, Eli would like a repro that does not involve selectrum/consult. That's out of my depth at the moment. I wouldn't even know where to begin. If anyone could help with that it'd be very much appreciated.

As an aside, vertico does in fact reproduce this, so it's not a selectrum specific issue.

[minad]

To be fair, Vertico is on ELPA and it changes less than Selectrum. Probably Icomplete-vertical is affected too by this. In order to generate a repro one could take Vertico and delete all non-drawing code. I wonder why Consult is involved in this? Do you see this in Vertico and only for consult-buffer?

[aaronjensen]

Actually, with my emacs -Q repro, vertico does not reproduce the issue. Only selectrum does. It appears that vertico also does not suffer from hscroll issues so I'm going to explore switching to it.

[aaronjensen]

Okay, so it seems I was actually getting an error from vertico when I tried to use it and that caused what I thought was reproducing it. It was because it was in mini-frame:

Error in post-command-hook (vertico--exhibit): (error "Cannot resize the root window of a frame")

If I disable mini-frame, vertico does not reproduce it. It's interesting though because it appears to be that extra resize step that corrects it. The mini frame size is still impacted by whether or not there is truncation going on, so it may be more that vertico /works around/ the issue, rather than does not exhibit it.

It looks like perhaps consult is not involved as I can reproduce odd sizing issues with just M-x and a very narrow window.

[aaronjensen]

(require 'selectrum)
(selectrum-mode)
(setq completion-styles '(substring))
(selectrum-completing-read
 "test: "
 '("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
   "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"))

Is the new repro without consult.

[minad]

Error in post-command-hook (vertico--exhibit): (error "Cannot resize the root window of a frame")

This is only because of miniframe. I haven't used miniframe before. If you find a way to fix Vertico with miniframe you can send a PR.

EDIT: I just tested mini-frame - this package is problematic. The candidates list is not updating, then there is this resize error and so on. I've had bugs in Consult too due to mini-frame since mini-frame executes the code in a different context than expected by minibuffer commands. Is this package widely used? After trying it for a while, I don't feel confident to recommend it.

EDIT2: With Selectrum it works a bit better. I don't know why. Probably the Vertico post command hooks are not executed properly. But it also very slow and there are update problems. This is also partially due to my setup where everything going through the window manager is slow. It would be better if Emacs would just draw the "child frames" itself on top of the existing window.

[aaronjensen]

mini-frame works fine for me on macOS with its window manager. And yes, vertico's post command hook being broken appears to break mini-frame entirely.

There's waaay too much going on in selectrum-completing-read so I'm having a hard time narrowing the repro any further.

[okamsn]

I am also seeing problems with long lines.

For example, in find-file, if the path is too long, then candidates won't be displayed at all. Instead, I only see the last part of the path that I am typing. If I widen the frame, then the candidates are revealed, but if I shrink the frame, the candidates are hidden again.

This is on Emacs 28.

Initial view:

After widening the frame:

After shrinking the frame again:

[aaronjensen]

@okamsn try on Emacs master and see if it's fixed. This was corrected upstream in Emacs 28 (not yet on native-comp, but you can merge master into that).

selectrum does not work well when you resize the frame while it's showing. The initial view seems odd, but it could be the same issue. If it's not, you may need to open a new issue w/ a specific repro.

[minad]

@aaronjensen Thank you for your help on fixing this bug in upstream. Greatly appreciated!

[aaronjensen]

@minad You're welcome!