* bug#1114: M-` results in huge minibuffer @ 2008-10-07 16:19 ` Geoff Gole 2008-10-07 17:05 ` Lennart Borgman (gmail) 2008-10-29 21:50 ` bug#1114: marked as done (M-` results in huge minibuffer) Emacs bug Tracking System 0 siblings, 2 replies; 4+ messages in thread From: Geoff Gole @ 2008-10-07 16:19 UTC (permalink / raw) To: bug-gnu-emacs 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)' ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1114: M-` results in huge minibuffer 2008-10-07 16:19 ` bug#1114: M-` results in huge minibuffer Geoff Gole @ 2008-10-07 17:05 ` Lennart Borgman (gmail) 2008-10-07 19:05 ` Geoff Gole 2008-10-29 21:50 ` bug#1114: marked as done (M-` results in huge minibuffer) Emacs bug Tracking System 1 sibling, 1 reply; 4+ messages in thread From: Lennart Borgman (gmail) @ 2008-10-07 17:05 UTC (permalink / raw) To: Geoff Gole, 1114 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1114: M-` results in huge minibuffer 2008-10-07 17:05 ` Lennart Borgman (gmail) @ 2008-10-07 19:05 ` Geoff Gole 0 siblings, 0 replies; 4+ messages in thread From: Geoff Gole @ 2008-10-07 19:05 UTC (permalink / raw) To: Lennart Borgman (gmail); +Cc: 1114 > > 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#1114: marked as done (M-` results in huge minibuffer) 2008-10-07 16:19 ` bug#1114: M-` results in huge minibuffer Geoff Gole 2008-10-07 17:05 ` Lennart Borgman (gmail) @ 2008-10-29 21:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 4+ messages in thread From: Emacs bug Tracking System @ 2008-10-29 21:50 UTC (permalink / raw) To: Chong Yidong [-- 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-10-29 21:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87vdvboz55.fsf@cyd.mit.edu> 2008-10-07 16:19 ` bug#1114: M-` results in huge minibuffer Geoff Gole 2008-10-07 17:05 ` Lennart Borgman (gmail) 2008-10-07 19:05 ` Geoff Gole 2008-10-29 21:50 ` bug#1114: marked as done (M-` results in huge minibuffer) Emacs bug Tracking System
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.