Minibuffer collapses to one line after some time

[hpdeifel]

Here's what happens if I reduce the number of candidates enough that they fit in less space than ivy-height:

1. Nothing, the candidates are displayed as before with empty lines filling the remaining space.
2. After a few seconds, the window collapses down to one line so I can' t see any candidates at all. (The candidate number is still displayed and correct)
3. After another few seconds, the window resizes again; now to the minimum height to display all candidates.

[hpdeifel]

I'm sorry, I can't reproduce that in a fresh emacs instance.

But nevertheless it happeed, so I'll try to reproduce it today close the bug if I can't. Maybe my emacs instance just was in some weird state

[abo-abo]

OK, thanks for reporting.

[hpdeifel]

Ok, I have an emacs instance that behaves that way, again. How can I debug the issue?

(The commonality between my two emacsen that showed the bug, that I can see right now, is: They were (fairly) long running (a day or so) and have a lot of tramp-buffers open)

[hpdeifel]

Ok, I reduced it: It happens if a tramp buffer with auto-revert-mode is open. Closing the buffer makes the issue go away.

Unfortunately only in my long-running emacs, not in a fresh instance. But at least, that could be a pointer to the right direction

[abo-abo]

Thanks a lot, I'll try to look into this soon. Can you eval ivy-height?

[hpdeifel]

I've set ivy-height to 20

[abo-abo]

And it's still 20 /during/ the bug?

[hpdeifel]

Ok, so I tried the following:

(defun hpd/trace-ivy-width ()
  (interactive "")
  (with-current-buffer (get-buffer-create "*ivy-height-trace*")
    (insert (format "ivy-heigth: %d\n" ivy-height))))

(define-key ivy-minibuffer-map (kbd "<f1>") 'hpd/trace-ivy-width)

Pressing F1 when the minibuffer is collapsed loggs ivy-height: 20, but also immediatly expands the buffer to the minimum needed width to display all candidates. (Just the same as what happens if I don't press F1 (or any other key for that matter) and instead wait a few seconds)

[abo-abo]

See if the last change helps. I'm just guessing here.

[hpdeifel]

Unfortunately that didn't fix it. But I tried to set resize-mini-windows permanently to t, and that prevents this bug from happening (it's not good workaround of course, since the constant size changing is irritating, but the bug doesn't occur)

[abo-abo]

Can you reliably reproduce the bug with tramp? Or you still have to keep a very long working session? Does the bug reoccur quickly once it happens for the first time? Could you try to reproduce with emacs -Q?

[hpdeifel]

No, I still can't reliably reproduce the bug, but it happens every time with tramp buffers and auto-revert-mode after a few hours (haven't tried to meassure the exact time). Also, if it occurs for the first time, it always does afterwards, until I close all tramp buffers. If I reopen them, the bug immediatly reappears.

[hpdeifel]

I almost thought this bug had fixed itself, when it happened again. But this time without tramp buffers but multiple emacsclient-frames open on the same server. Also, this time it was shortly after the start of the emacs server.

I still cannot reproduce it reliably and also haven't been able to see it in emacs -Q, yet.

[tumashu]

1. if you set minibuffer truncate-line to t, menu disapear
2. if main window too small, menu disapear too.

[hpdeifel]

Nice! I haven't used multiple-frame configurations in the last months, but I'll see If I can still reproduce this. Would be really nice if it's fixed

[amosbird]

When truncate-line is t, this issue still exists.

Here is the reproduce steps,

make plain
eval (add-hook 'minibuffer-setup-hook (lambda () (interactive) (setq-local truncate-lines t)))
C-x C-f
M-o

tested on archlinux, emacs 27.0.50