counsel-yank-pop and ivy take up the entire screen for candidates with multiple lines

[sriramkswamy]

This is in reference to this reddit post - https://redd.it/3vd7lf

When the candidates span multiple lines, ivy takes up the entire screen - https://i.imgur.com/2H3wWJz.jpg

[josuah]

I've seen this variable: counsel-yank-pop-truncate, and it is used in counsel-yank-pop's function, but setting counsel-yank-pop-truncate to t does not change anything for me.

[sriramkswamy]

From describe-variable:

counsel-yank-pop-truncate is a variable defined in `counsel.el'.
Its value is nil

Documentation:
When non-nil, truncate the display of long strings.

You can customize this variable.

So I'm guessing it controls what happens when the length of the string exceeds your screen width and
not truncate the length based on height, which is the number of lines that is displayed in the mini buffer candidate.

[ghost]

counsel-yank-pop-truncate truncates the height of each candidate to 4 lines by changing the display to show [...] on the truncated line. That said, if you have several entries > 4 lines, and ivy showing 10 candidates, it can still take up to 40 lines on screen.

One possible solution to this issue might be to have ivy--format throw away candidates such that it displays ivy-height lines (by counting \n) rather than ivy-height candidates. If the last candidate has excess newlines, the display is truncated to fit.

In this situation, ivy might only display 1 truncated candidate at a time, if the body were larger than ivy-height.

Thoughts?

A different solution would be to squash each candidate's display to a single line (\n and \s{3,} represented as double space), but I tested this out and it looks pretty weird.

[sriramkswamy]

Ah, I had just tried it with a couple of lines. I updated it and tried and you are right. It does show [...] for anything more than 4 lines.

I'm not really experienced enough to comment on solutions but as a user, shrinking it to 4 lines has me satisfied.

[josuah]

@sriramkswamy: Oh, yes obviously! It seems was not careful enough while reading. Then the truncation should occur after the lines have been truncated.

I do not see any existing customization yet, but if the number 4 appear as is in the source file, changing it to 1 line may solve this problem.

Although, I like the proposition of @thwg.

[abo-abo]

Please have a look:

During the completion, only the context around the match will be shown. By default, the context is +2 lines above and +2 lines below the match. It can be adjusted with counsel-yank-pop-truncate-radius'. Additionally,ivy-height' is temporarily bound to 5 during completion. This way, the maximum minibuffer height should be 1+4*5=21 lines.

[josuah]

I'm thanking you, but it does not work for me:
GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of 2015-09-10 on foutrelis

I cloned the repository in ~, and emacs -nw -Q, I evaluated the following

(add-to-list 'load-path "~/swiper")
(require 'counsel)

Then copied the content of the buffer, modified it because it seems that duplicates are removed from counsel-yonk-pop, which is nice) then copied it again. I did it until I had 4 completion candidates.

The result is here (and also behove like that with a bigger screen.

M-x counsel-yank-pop RET

C-n

C-n

C-n

The minibuffer is indeed smaller (the same behavior with larger window), but a little bit too much it seems.

The last commit is this one:

commit 8c2f213d911bb10c01a794eaaf0121ccb25d40ff
Author: abo-abo <***@***>
Date:   Thu Jan 28 17:37:23 2016 +0100

On the other hand, I like the principle you introduced.

[abo-abo]

Thanks for the report. I can reproduce (only with emacs -nw though). I'll look into why this is happening later.

For now, I really recommend using the graphical Emacs. It's much better in almost all respects.

[josuah]

That is great, thank you!