Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Number of candidates is not being affected by selectrum-num-candidates-displayed #22

Closed
Luis-Henriquez-Perez opened this issue Feb 26, 2020 · 9 comments

Comments

@Luis-Henriquez-Perez
Copy link
Contributor

I've set selectrum-num-candidates-displayed to 30. But I'm still only seeing 10 candidates (including the prompt). I'm at commit 548903e, which is the latest as I'm writing this. And I've confirmed selectrum mode is enabled by evaluating selectrum-mode. I've also tried rebuilding selectrum and starting a new emacs session.

@raxod502
Copy link
Member

Thanks for the report, I can confirm it. There seems to be a limit imposed by Emacs on the total height of the minibuffer, as the candidates are still displayed and selectable, just not visible in the frame.

@Luis-Henriquez-Perez
Copy link
Contributor Author

There seems to be a limit imposed by Emacs on the total height of the minibuffer

Indeed. This seems to be the variable max-mini-window-height according to this stackoverflow question. I set it from 0.3 ot 0.5 and this allowed more candidates to be visible in the frame (though not yet 30).

@raxod502
Copy link
Member

I guess Selectrum should rebind that variable locally to the number candidates displayed plus one.

@Luis-Henriquez-Perez
Copy link
Contributor Author

I guess Selectrum should rebind that variable locally to the number candidates displayed plus one.

Well, that number is the proportion of the frame that the minibuffer should occupy. So I think the value of that number would have to be a function of line height (relative to the size of the frame) and the number of candidates we want to display.

@Luis-Henriquez-Perez
Copy link
Contributor Author

Forget what I just said. I took a peek at ivy's source code. I think we can do it essentially the way you suggested. I think this snippet is the way to do it.

In ivy--minibuffer-setup I see the minibuffer height set this way (I simplified the code a bit):

 (set-window-text-height nil height)

In ivy-minibuffer-grow/shrink:

(setq-local max-mini-window-height (cl-incf ivy-height)) ;; essentially what you said

raxod502 added a commit that referenced this issue Apr 17, 2020
@raxod502
Copy link
Member

Let me know if you encounter any further difficulty.

@raxod502 raxod502 added the waiting on response Needs more info or follow-up, will be closed after 90 days if no response label Apr 17, 2020
@Luis-Henriquez-Perez
Copy link
Contributor Author

It looks good to me. I'll post a gif here when I can so people reading this will understand what the new behavior is.

@Luis-Henriquez-Perez
Copy link
Contributor Author

output-2020-04-22-19:49:21

@raxod502 raxod502 removed the waiting on response Needs more info or follow-up, will be closed after 90 days if no response label Apr 23, 2020
@raxod502
Copy link
Member

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants