How large is the minibuffer window by default?

[vherrmann]

This is just a sort-of personal question (which could be relevant to others), so you can close this immediately in case you want to.

I have the following problem. I use vertico with doom emacs and all other consult commands I use take up ca. 1/3 of the screen:

To the contrary, consult-lsp-diagnostics can take up almost all of my screen:

So I wonder if you could help me limit this to 1/3 of the screen.

[gagbo]

Hello,

A wild guess about how minibuffer height is handled

It looks like the issue is that Emacs checks for the "max height" condition only after it already added the next candidate, like

Add candidate in the minibuffer
Check minibuffer height
If too big, stop
else continue

And since the diagnostics here are multiline and fully rendered, adding one diagnostic which is very high (because it's a multiline candidate) kind of breaks the height limit.

@minad do you know if/how consult and vertico tries to limit the minibuffer height ? I wonder if my assumption about the mechanics is correct or not.

A fix ?

This comes back to "How do we want to handle multiline candidates?". I know that minad preferred to heavily truncate the results if they are too long/multiline, in my most common cases (Clangd and Rust-analyzer diagnostics) it was mostly fine to have all the lines so I didn't bother truncating everything. Now that I see really big diagnostics coming, I think I'll have to truncate them.

The choice of truncation/not truncation is done in the transformer (I assume that you knew this, and it's kind of the reason for your PR), It used to replace newlines with spaces and then let Emacs deal with the awfully long lines. Then I changed it to only use the raw diagnostic thinking I would test this and see if it's good or not.

It seems that it's not good after all (I expect that the height control mechanism is not something I can easily fix), so I'll probably revert that commit soon-ish

[minad]

This is not Vertico. (EDIT: @vherrmann mentioned that he uses Vertico, but Vertico should wrap newlines in any case so something else is wrong here. As I understand, @gagbo, consult-lsp produces annotations with newlines. This is unsupported.)

[vherrmann]

It looks like the issue is that Emacs checks for the "max height" condition only after it already added the next candidate, like

@gagbo This doesn't seem to be the case:

Maybe emacs computes how many lines the minibuffer should have and uses the same number of strings, which in this case are longer than just one line.

[vherrmann]

It seems that it's not good after all (I expect that the height control mechanism is not something I can easily fix), so I'll probably revert that commit soon-ish

Hmm, I actually kind of like it with multiple-lines, since its much harder to read the haskell diagnostics with them being truncated in one line.

EDIT: though I probably could use consult to get to a certain error and then show the specific error in a popup or sth.

[gagbo]

Vertico should wrap newlines in any case so something else is wrong here

I forgot about this part sorry, and it's not the first time you told me that :( I'll toy with the annotations then.

(FTR, indeed consult-lsp creates a raw multi-line annotation from the results)