bug#1114: M-` results in huge minibuffer

bug#1114: M-` results in huge minibuffer

[Geoff Gole]

In certain conditions M-` will cause emacs to display a huge
minibuffer, occupying most of the frame. To replicate:

start an emacs -Q
C-x 3
M-`

This seems to mostly occur when the frame contains only vertical
splits (that's vertical as in C-x 3), but in some cases a window setup
containing a horizontal split also shows the bug.

Some example key sequences, each starting from a fresh emacs with
exactly one window:

M-` -> fine
C-x 3 M-` -> bug
C-x 3 C-x 3 M-` -> bug
C-x 3 C-x 2 M-` -> fine
C-x 3 C-x 3 C-x o C-x o C-x 2 M-` -> bug
C-x 3 C-x 3 C-x 2 M-` -> fine

I hope that's clear.

GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600) of 2008-03-26 on RELEASE
Also observed in GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of
2007-08-18 on TPAD

Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

bug#1114: M-` results in huge minibuffer

[Lennart Borgman (gmail)]

Geoff Gole wrote:
> In certain conditions M-` will cause emacs to display a huge
> minibuffer, occupying most of the frame. To replicate:
> 
> start an emacs -Q
> C-x 3
> M-`
> 
> This seems to mostly occur when the frame contains only vertical
> splits (that's vertical as in C-x 3), but in some cases a window setup
> containing a horizontal split also shows the bug.
> 
> Some example key sequences, each starting from a fresh emacs with
> exactly one window:
> 
> M-` -> fine
> C-x 3 M-` -> bug
> C-x 3 C-x 3 M-` -> bug
> C-x 3 C-x 2 M-` -> fine
> C-x 3 C-x 3 C-x o C-x o C-x 2 M-` -> bug
> C-x 3 C-x 3 C-x 2 M-` -> fine
> 
> I hope that's clear.


I think the reason might be the call to fit-window-to-buffer in
Electric-pop-up-window.

bug#1114: M-` results in huge minibuffer

[Geoff Gole]

>
> I think the reason might be the call to fit-window-to-buffer in
> Electric-pop-up-window.
>

I took a look. The minibuffer indeed changes size due to a call to
enlarge-window inside fit-window-to-buffer.

It seems that while enlarge-window doesn't usually touch the
minibuffer, it will take effect when inside a completing-read. For
example:

  (let ((win (selected-window)))
    (completing-read "Test prompt : "
     (lambda (&rest *)
       (with-selected-window win
         (enlarge-window -10))))) ; minibuffer will grow ten lines

Further up the call stack I see tmm-prompt makes such a call to
completing-read, so it seems likely that is the problem. I have no
fix, though.

bug#1114: marked as done (M-` results in huge minibuffer)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]


Your message dated Wed, 29 Oct 2008 17:43:50 -0400
with message-id <87vdvboz55.fsf@cyd.mit.edu>
and subject line Re: M-` results in huge minibuffer
has caused the Emacs bug report #1114,
regarding M-` results in huge minibuffer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
1114: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1114
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3796 bytes --]

From: "Geoff Gole" <geoffgole@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: M-` results in huge minibuffer
Date: Tue, 7 Oct 2008 09:19:12 -0700
Message-ID: <f5bc73230810070919wceef8a2g4c35c11a75bd0c58@mail.gmail.com>

In certain conditions M-` will cause emacs to display a huge
minibuffer, occupying most of the frame. To replicate:

start an emacs -Q
C-x 3
M-`

This seems to mostly occur when the frame contains only vertical
splits (that's vertical as in C-x 3), but in some cases a window setup
containing a horizontal split also shows the bug.

Some example key sequences, each starting from a fresh emacs with
exactly one window:

M-` -> fine
C-x 3 M-` -> bug
C-x 3 C-x 3 M-` -> bug
C-x 3 C-x 2 M-` -> fine
C-x 3 C-x 3 C-x o C-x o C-x 2 M-` -> bug
C-x 3 C-x 3 C-x 2 M-` -> fine

I hope that's clear.

GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600) of 2008-03-26 on RELEASE
Also observed in GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of
2007-08-18 on TPAD

Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'




[-- Attachment #3: Type: message/rfc822, Size: 1347 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: "Geoff Gole" <geoffgole@gmail.com>
Cc: "Lennart Borgman \(gmail\)" <lennart.borgman@gmail.com>, 1114-done@emacsbugs.donarmstrong.com
Subject: Re: M-` results in huge minibuffer
Date: Wed, 29 Oct 2008 17:43:50 -0400
Message-ID: <87vdvboz55.fsf@cyd.mit.edu>

> > In certain conditions M-` will cause emacs to display a huge
> > minibuffer, occupying most of the frame.
>
> I think the reason might be the call to fit-window-to-buffer in
> Electric-pop-up-window.

Lennart's correct.  I've checked in a tweak to Electric-pop-up-window
that should prevent this from happening.  Thanks for the bug report.