number of results displayed in minibuffer shrinks after visiting a long multi-line result

[ChrisWills]

This issue manifests when scrolling through the ivy minibuffer after running something like counsel-rg which could contain very long matches. Upon visiting a match that is long enough that it exceeds the width of the minibuffer and then scrolling past is such that all results currently displayed each fit on one line, the number of displayed results is reduced by one.

Here is a simple reproducer. Initially 5 results are displayed but once you visit the long line, only 4 results are displayed for the remaining life of the minibuffer.

My desired behavior here is that once we pass the long entry, we go back to displaying 5 single line entries.

(setq ivy-height 5)
(ivy-read "test: " '( "one" "two" "four" "five" "six" "seven" "eight" "ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt" ))

[basil-conto]

the number of displayed results is reduced by one

I can reproduce this neither in a graphical nor a text-based Emacs session. Under a graphical terminal, the wide ninth candidate is truncated, and neither the height of the minibuffer nor the number of candidates displayed changes. Under a text terminal, the ninth candidate is not truncated; instead, the height of the minibuffer is increased by one screen line for the remainder of the completion session, but the number of candidates shown at any given time remains the same. Here's what I mean:

1. make plain

2. (setq ivy-height 5)

   C-j

3. (ivy-read "prompt: " (nconc (mapcar #'number-to-string
                                       (number-sequence 0 (* ivy-height 2)))
                               (list (make-string (* (frame-width) 2) ?w))))

   C-j

   

4. M->

   

5. M-<

   

Note the minibuffer maintains a constant height of 5 screen lines, showing 4 completion candidates. Compare this with a text-based session:

1. make emacs='emacs -nw' plain

2. (setq ivy-height 5)

   C-j

3. (ivy-read "prompt: " (nconc (mapcar #'number-to-string
                                       (number-sequence 0 (* ivy-height 2)))
                               (list (make-string (* (frame-width) 2) ?w))))

   C-j

   

4. M->

   
   Note the height of the minibuffer has increased to accommodate the wide 12th candidate, but the number of candidates on display hasn't changed.

5. M-<

   
   Note the height of the minibuffer remains larger than it was at the beginning of the completion session, but the number of candidates on display hasn't changed.

I tested the recipes above with the following three versions of Emacs:

In GNU Emacs 25.2.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2018-08-27, modified by Debian built on x86-csail-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description:	Debian GNU/Linux testing (buster)

In GNU Emacs 26.1.50 (build 6, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2018-11-01 built on thunk
Repository revision: d53a2b65db9952580efcf5ffe75a313bcb49a99e
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description:	Debian GNU/Linux testing (buster)

In GNU Emacs 27.0.50 (build 53, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2018-11-16 built on thunk
Repository revision: 644a308b4e1513e04be9360e1586e14b32ec0159
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid

My desired behavior here is that once we pass the long entry, we go back to displaying 5 single line entries.

Are you able to reproduce the issue starting from emacs -Q or make plain? What is your full M-xemacs-versionRET and version of Ivy? If you are on Emacs 25 or newer, what is your value of resize-mini-windows? Have you tried setting it to t instead of the default grow-only? Are you running Emacs under a graphical or a text terminal? Are you able to provide a more detailed and/or reproducible recipe, perhaps accompanied by screenshots?

[ChrisWills]

Thanks very much for your detailed reply!

I am running emacs in the terminal and as it turns out I'm getting the exact same behavior that you described above. I was wrong when I said the number of displayed entries is reduced, it is just that the mini-buffer grows leaving an awkward blank area as you described.

Setting resize-mini-windows to t instead of grow-only gives me the behavior I'm looking for so that's perfect.

Thanks and apologies for the confusion!

[basil-conto]

Setting resize-mini-windows to t instead of grow-only gives me the behavior I'm looking for so that's perfect.

I'm glad to hear.

I noticed an issue when resize-mini-windows is t, however; see #1809.

[basil-conto]

FWIW, there also exist the commands ivy-minibuffer-grow and ivy-minibuffer-shrink, bound to C-o> and C-o< by default (when the ivy-hydra package is installed), respectively; see (ivy) Hydra in the minibuffer.