Handle situations when actual height of minibuffer is not enough.

[AmaiKinono]

There's a variable max-mini-window-height that controls the maximum height of the minibuffer window, and it can cause the actual height being smaller than (1+ selectrum-num-candidates-displayed). So this may happen:

selectrum-num-candidates-displayed is 10, but the actual height of the minibuffer is 9, so the cursor goes outside of the boundary.

Besides, multi-line candidates also cause problem, like when browsing a kill-ring:

[raxod502]

Good catch. I think both problems can be solved by the same fix. We just have to keep track of the actual number of display lines as candidates are inserted, and stop at the appropriate point.

[AmaiKinono]

I just notice that the next/prev page commands also have this problem. They should be fixed too.

[raxod502]

Let me know what you think of this implementation.

[AmaiKinono]

I've tested it and read the code. The "undesirable gradual scrolling effect" you described actually doesn't only happen for long candidates, but also when the height of the minibuffer is small (due to max-mini-window-height) and the user holds C-n to scroll down.

I think the implementation is acceptable from a user's perspective, and I doubt whether it can be done better.

[raxod502]

I think the implementation is acceptable from a user's perspective

OK, closing.

The "undesirable gradual scrolling effect" you described actually doesn't only happen for long candidates, but also when the height of the minibuffer is small

Oh really? That's surprising to me, from my understanding of the algorithm it should be impossible for the scrolling case to trigger unless there is a multiline candidate somewhere. Are there particular conditions you have to follow to get this behavior?

[AmaiKinono]

Are there particular conditions you have to follow to get this behavior?

No, just resize the window so you can't have a minibuffer that satisfies selectrum-num-candidates-displayed, and run any command like M-x, and hold C-n. I'm sure there aren't any multiline candidate in M-x.

I tried to record a gif, but it can't show the problem. I also tested using emacs -Q, the problem exists, but not so intense (to my eyes it's like the current candidate blinks sometimes, which should be caused by a really fast "gradual scroll"). My guess is it has something to do with the performance of my configuration and maybe my PC.

[raxod502]

I can see that as well. You could open a new issue for it if you like.