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

Minibuffer collapses to one line after some time #77

Closed
hpdeifel opened this Issue May 4, 2015 · 16 comments

Comments

Projects
None yet
4 participants
@hpdeifel

hpdeifel commented May 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 4, 2015

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

hpdeifel commented May 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@abo-abo

abo-abo May 4, 2015

Owner

OK, thanks for reporting.

Owner

abo-abo commented May 4, 2015

OK, thanks for reporting.

@hpdeifel

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 5, 2015

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 commented May 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 5, 2015

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

hpdeifel commented May 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@abo-abo

abo-abo May 5, 2015

Owner

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

Owner

abo-abo commented May 5, 2015

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

@hpdeifel

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 6, 2015

I've set ivy-height to 20

hpdeifel commented May 6, 2015

I've set ivy-height to 20

@abo-abo

This comment has been minimized.

Show comment
Hide comment
@abo-abo

abo-abo May 6, 2015

Owner

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

Owner

abo-abo commented May 6, 2015

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

@hpdeifel

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 6, 2015

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)

hpdeifel commented May 6, 2015

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 added a commit that referenced this issue May 6, 2015

Try to prevent the resize of minibuffer window
* ivy.el (ivy--insert-minibuffer): Temporarily bind
  `resize-mini-windows' to nil.

From its doc:
    A value of `grow-only', the default, means let mini-windows grow only;
    they return to their normal size when the minibuffer is closed, or the
    echo area becomes empty.

It could be that an update catches this minibuffer empty during
`ivy--insert-minibuffer'.

Re #77
@abo-abo

This comment has been minimized.

Show comment
Hide comment
@abo-abo

abo-abo May 6, 2015

Owner

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

Owner

abo-abo commented May 6, 2015

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

@hpdeifel

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 6, 2015

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)

hpdeifel commented May 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@abo-abo

abo-abo May 6, 2015

Owner

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?

Owner

abo-abo commented May 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 6, 2015

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 commented May 6, 2015

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.

@abo-abo abo-abo added the bug label May 11, 2015

@hpdeifel

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel May 13, 2015

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.

hpdeifel commented May 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@tumashu

tumashu May 15, 2015

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

tumashu commented May 15, 2015

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

@abo-abo abo-abo closed this in d8d7ed4 Sep 19, 2015

@hpdeifel

This comment has been minimized.

Show comment
Hide comment
@hpdeifel

hpdeifel Sep 19, 2015

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

hpdeifel commented Sep 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@amosbird

amosbird Mar 13, 2018

Contributor

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

Contributor

amosbird commented Mar 13, 2018

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

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