GNU bug report logs - #1291
23.0.60; 1) resize-mini-windows: customizable, 2) if grow mini, grow Completions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1291 in the body.
You can then email your comments to 1291 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <emacs-pretest-bug <at> gnu.org>
Subject: 23.0.60; 1) resize-mini-windows: customizable, 2) if grow mini, grow Completions
Date: Sat, 1 Nov 2008 17:16:33 -0700

This bug appears also in Emacs 22 - please backport the fix.

1. Variable `resize-mini-windows' should be a customizable option. It
is obviously intended to be modified by users.
 
2. 
emacs -Q
M-x load-library tmm
M-x tmm-menubar
 
You'll see that not all candidates in *Completions* are visible. This
is true in spite of the fact that `tmm-menubar' calls
Electric-pop-up-window' which correctly fits the *Completions* window
to the buffer.
 
The problem is that (assuming `resize-mini-window' is non-nil) when
the minibuffer grows to accommodate the default completion candidate
that is inserted in the minibuffer, it takes vertical space away from
*Completions*.
 
Whenever the minibuffer is grown, so should *Completions* be grown to
the same extent (modulo some maximum setting). Otherwise, fitting the
*Completions* window is defeated by the minibuffer resizing.
 
Please fix this in the Lisp code, not the C code, so other libraries
that manipulate the minibuffer differently from vanilla Emacs can also
benefit.
 
 
 
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-10-09 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

Message #10 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 1291 <at> debbugs.gnu.org
Cc: Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Sun, 02 Nov 2008 15:12:20 +0100

> emacs -Q
> M-x load-library tmm
> M-x tmm-menubar
>
> You'll see that not all candidates in *Completions* are visible. This
> is true in spite of the fact that `tmm-menubar' calls
> Electric-pop-up-window' which correctly fits the *Completions* window
> to the buffer.

IIUC, the *Completions* window is not shrunk any more due to

2008-10-29  Chong Yidong  <cyd <at> stupidchicken.com>

	* electric.el (Electric-pop-up-window): Don't shrink the window if
	it's already big enough.

So please retry with the latest version of electric.el.

martin

Message #15 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>, <1291 <at> debbugs.gnu.org>
Cc: <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow	Completions
Date: Sun, 2 Nov 2008 06:49:54 -0800

> From: martin rudalics Sent: Sunday, November 02, 2008 6:12 AM
> To: 1291 <at> emacsbugs.donarmstrong.com
> 
>  > emacs -Q
>  > M-x load-library tmm
>  > M-x tmm-menubar
>  >
>  > You'll see that not all candidates in *Completions* are 
>  > visible. This is true in spite of the fact that `tmm-menubar'
>  > calls Electric-pop-up-window' which correctly fits the 
>  > *Completions* window to the buffer.
> 
> IIUC, the *Completions* window is not shrunk any more due to
> 
> 2008-10-29  Chong Yidong  <cyd <at> stupidchicken.com>
> 	* electric.el (Electric-pop-up-window): Don't shrink 
>     the window if it's already big enough.
> 
> So please retry with the latest version of electric.el.

Hey, you guys are way ahead of me again. ;-)

Looks good. Thanks!

Message #20 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>, <1291 <at> debbugs.gnu.org>
Cc: <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow	Completions
Date: Sun, 2 Nov 2008 07:12:03 -0800

[Message part 1 (text/plain, inline)]

> From: Drew Adams Sent: Sunday, November 02, 2008 6:50 AM
> >  > emacs -Q
> >  > M-x load-library tmm
> >  > M-x tmm-menubar
> >  >
> >  > You'll see that not all candidates in *Completions* are 
> >  > visible. This is true in spite of the fact that `tmm-menubar'
> >  > calls Electric-pop-up-window' which correctly fits the 
> >  > *Completions* window to the buffer.
> > 
> > IIUC, the *Completions* window is not shrunk any more due to
> > 
> > 2008-10-29  Chong Yidong  <cyd <at> stupidchicken.com>
> > 	* electric.el (Electric-pop-up-window): Don't shrink 
> >     the window if it's already big enough.
> > 
> > So please retry with the latest version of electric.el.
> 
> Hey, you guys are way ahead of me again. ;-)
> Looks good. Thanks!

Ooops. I wrote that before I actually tried it. ;-) Actually, it's worse than
before: cuts off more of the candidates in *Completions*.

I forgot to mention in the recipe above to resize the frame so that it is only,
say, 40 chars wide (keeping the height the same). Do that before calling
`tmm-menubar'.

Previously (2008-10-09 build), the *Completions* buffer showed all of the
candidates through `s==>Subdir', e.g. when I try it in a Dired buffer. It only
left out one line, with the candidate `h==>Help'. Now, *Completions* leaves out
all of these candidates:

t==>Tools
o==>Operate
m==>Mark
r==>Regexp
i==>Immediate
s==>Subdir
h==>Help

Before, *Completions* is 22 screen lines high (with frame width 40 and height
43. Now, it is only 17 screen lines high. It's as if *Completions* were not fit
to the candidates at all now.

See attached screenshot. On the left is the 2008-10-09 build; on the right is
the same 2008-10-09 build, but after loading today's CVS version of electric.el.

Sorry for the bad news. Thx - Drew

[bug-tmm-menubar-electric.png (image/png, attachment)]

Message #25 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 1291 <at> debbugs.gnu.org, nuxdoors <at> cegetel.net
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Sun, 02 Nov 2008 19:14:55 +0100

> Previously (2008-10-09 build), the *Completions* buffer showed all of the
> candidates through `s==>Subdir', e.g. when I try it in a Dired buffer. It only
> left out one line, with the candidate `h==>Help'. Now, *Completions* leaves out
> all of these candidates:

I'm afraid we won't get this very right ever.  But you could try the
below version of `Electric-pop-up-window'.

martin

(defun Electric-pop-up-window (buffer &optional max-height)
  (let* ((win (or (get-buffer-window buffer) (selected-window)))
	 (buf (get-buffer buffer))
	 (one-window (one-window-p t))
	 (pop-up-windows t)
	 (pop-up-frames nil))
    (if (not buf)
	(error "Buffer %s does not exist" buffer)
      (cond ((and (eq (window-buffer win) buf))
	     (select-window win))
	    (one-window
	     (pop-to-buffer buffer)
	     (setq win (selected-window)))
	    (t
	     (switch-to-buffer buf)))
      ;; Don't shrink the window, but expand it if necessary.
      (goto-char (point-min))
      (unless (<= (point-max) (window-end win t))
	(fit-window-to-buffer win max-height))
      win)))

Message #30 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: <1291 <at> debbugs.gnu.org>, <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow	Completions
Date: Sun, 2 Nov 2008 11:05:35 -0800

> From: martin rudalics Sent: Sunday, November 02, 2008 10:15 AM
>  > Previously (2008-10-09 build), the *Completions* buffer 
>  > showed all of the candidates through `s==>Subdir', e.g.
>  > when I try it in a Dired buffer. It only left out one line,
>  > with the candidate `h==>Help'. Now, *Completions* leaves out
>  > all of these candidates:
> 
> I'm afraid we won't get this very right ever.  But you could try the
> below version of `Electric-pop-up-window'.
> 
> martin
> 
> (defun Electric-pop-up-window (buffer &optional max-height)
>    (let* ((win (or (get-buffer-window buffer) (selected-window)))
> 	 (buf (get-buffer buffer))
> 	 (one-window (one-window-p t))
> 	 (pop-up-windows t)
> 	 (pop-up-frames nil))
>      (if (not buf)
> 	(error "Buffer %s does not exist" buffer)
>        (cond ((and (eq (window-buffer win) buf))
> 	     (select-window win))
> 	    (one-window
> 	     (pop-to-buffer buffer)
> 	     (setq win (selected-window)))
> 	    (t
> 	     (switch-to-buffer buf)))
>        ;; Don't shrink the window, but expand it if necessary.
>        (goto-char (point-min))
>        (unless (<= (point-max) (window-end win t))
> 	(fit-window-to-buffer win max-height))
>        win)))

That seems to give the same behavior as the build of 2008-10-09: The last line
is still not included in the *Completions* window. 

The problem is not that the *Completions* window is not fit properly by
Electric-pop-up-window - it is. The problem is that after fitting it the
minibuffer expansion reduces the *Completions* window. It should not.

There ought to be a way to respect the *Completions* window size that we go to
the trouble of creating by calling `fit-window-to-buffer'.

Message #35 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 1291 <at> debbugs.gnu.org, nuxdoors <at> cegetel.net
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Sun, 02 Nov 2008 20:45:33 +0100

> The problem is not that the *Completions* window is not fit properly by
> Electric-pop-up-window - it is. The problem is that after fitting it the
> minibuffer expansion reduces the *Completions* window. It should not.

There's nothing special about the *Completions* window once it has been
handled by `fit-window-to-buffer', so resizing the minibuffer won't care
about it specially.

> There ought to be a way to respect the *Completions* window size that we go to
> the trouble of creating by calling `fit-window-to-buffer'.

We could fix the window's height (but I don't want to think of the
complaints).  So maybe, we should provide additional values for
`window-size-fixed' like 'lax-height and 'lax-weight thus Emacs would
try to shrink some other window first.

martin

Message #40 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: <1291 <at> debbugs.gnu.org>, <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow	Completions
Date: Sun, 2 Nov 2008 12:27:02 -0800

> From: martin rudalics Sent: Sunday, November 02, 2008 11:46 AM
>  > The problem is not that the *Completions* window is not 
>  > fit properly by Electric-pop-up-window - it is. The problem
>  > is that after fitting it the minibuffer expansion reduces
>  > the *Completions* window. It should not.
> 
> There's nothing special about the *Completions* window once 
> it has been handled by `fit-window-to-buffer', so resizing the
> minibuffer won't care about it specially.

It should care about it specially. There _is_ something special about
*Completions* wrt the minibuffer. The only reason for *Completions* to exist
during minibuffer completion is to serve the minibuffer - it is made for the
minibuffer. And the minibuffer should play well with *Completions* during
minibuffer completion. They should work hand in hand.

If our treatment of the minibuffer is ignoring *Completions* and whatever we do
to benefit *Completions* display, such as make its window fit the current
(minibuffer) completions, then something is wrong with our treatment of the
minibuffer.

It is a mistake to think that the minibuffer and *Completions* should be treated
independently, should be treated as just any old buffers and windows. They are
not independent during minibuffer completion; they belong together. Both of them
are special, in several respects.

That is not to say that the minibuffer display can never override whatever is
decided for the *Completions* display, but it should not do so gratuitously. It
should take the *Completions* display into account.

>  > There ought to be a way to respect the *Completions* 
>  > window size that we go to the trouble of creating by
>  > calling `fit-window-to-buffer'.
> 
> We could fix the window's height (but I don't want to think of the
> complaints).  So maybe, we should provide additional values for
> `window-size-fixed' like 'lax-height and 'lax-weight thus Emacs 
> would try to shrink some other window first.

I don't really follow that (I'm not familiar with `window-size-fixed'), and I
can't necessarily speak to how this should be implemented in any case. I'm just
reporting a (minor) bug. 

But I don't think this should be fixed in some general way, treating the
*Completions* or minibuffer window in the same way as any other window. If
that's what you're suggesting wrt `window-size-fixed', then I think that's
probably not the best approach. 

These are somewhat special windows/buffers - they should be dealt with together
(during minibuffer completion). This is a particular problem for minibuffer
completion, I think, not a problem for windows in general or even other windows
whenever the minibuffer is active. Minibuffer + *Completions* is a special case.

To me, it doesn't make sense for Peter to resize the *Completions* window and
Paul to then resize the minibuffer without taking into account what Peter has
just tried to do. If Paul takes Peter's intention and action into account and
then overrides Peter's action according to some more important consideration,
that's OK. But Paul should not just ignore Peter's good work.

Message #45 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 1291 <at> debbugs.gnu.org, nuxdoors <at> cegetel.net
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Mon, 03 Nov 2008 08:17:10 +0100

> That is not to say that the minibuffer display can never override whatever is
> decided for the *Completions* display, but it should not do so gratuitously. It
> should take the *Completions* display into account.

Ideally, yes.  But, as I said before, we first need a mechanism that
allows us to establish a connection between such windows and the
minibuffer (we could try to fit a window to its buffer _after_ resizing
the minibuffer, but it's obvious how fragile such a solution would be).

> But I don't think this should be fixed in some general way, treating the
> *Completions* or minibuffer window in the same way as any other window. If
> that's what you're suggesting wrt `window-size-fixed', then I think that's
> probably not the best approach.

FAIK the *Completions* windows and the minibuffer are independent from
each other.  So we have to find a mechanism to tell the window
management part what to do.  Fixing window sizes in some "lax" fashion
is one way to do that.

martin

Message #50 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: <1291 <at> debbugs.gnu.org>, <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow	Completions
Date: Mon, 3 Nov 2008 00:21:18 -0800

> FAIK the *Completions* windows and the minibuffer are independent from
> each other.  So we have to find a mechanism to tell the window
> management part what to do.  Fixing window sizes in some "lax" fashion
> is one way to do that.

AFAIK, the main functions that complete minibuffer input and display possible
completions use buffer *Completions* for that display.
`minibuffer-completion-help' and `switch-to-completions', for example, are used
by the standard minibuffer completion keymaps, and they both use *Completions*.
Likewise, Pcomplete and Iswitchb use *Completions*. Ido uses the value of
`ido-completion-buffer', however.

Seems a good enough heuristic that for minibuffer completion the completions are
displayed in a window showing buffer *Completions*, if they are displayed at all
(`completion-show-help'). Not 100% fail-safe, perhaps, but it should be possible
to nail things down pretty well, if necessary, to make sure that a displayed
*Completions* buffer in `completion-list-mode' is showing the current
completions for the active minibuffer currently completing.

In practice, I don't think such nails are really needed. Both
`minibuffer-completion-help' and `switch-to-completions' simply rely on
(get-buffer-window "*Completions*"), and that seems to suffice to determine the
completions window. However, I suggest using 0 for the FRAME arg to
`get-buffer-window', since *Completions* might be on a different frame from the
minibuffer (e.g. standalone minibuffer, special-display *Completions*).

So I guess I don't see the independence you mention. During minibuffer
completion, a visible window showing buffer *Completions* is the one whose size
the minibuffer should care about. If there is no such window, e.g. because the
completions buffer has a different name, then the minibuffer won't take the
completions window into account for its resizing - but in that corner case we
are no worse off than now.

In sum, if *Completions* is visible during minibuffer completion, then the
minibuffer should take its window into account. If not, it need not worry about
it.

Message #55 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 1291 <at> debbugs.gnu.org, nuxdoors <at> cegetel.net
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Mon, 03 Nov 2008 09:58:34 +0100

> In sum, if *Completions* is visible during minibuffer completion, then the
> minibuffer should take its window into account. If not, it need not worry about
> it.

Ever since 1999 this is handled by Gerd's shrink_window_lowest_first
function.  That function takes lines from the window above the
minibuffer window and IIUC currently doesn't even care about fixed-size
windows.  It certainly doesn't care about what _kind of buffer_ is
displayed in that window.  Moreover, the code responsible for re-growing
the window after the minibuffer is re-shrunk will grow the lowest window
again and we'll be left with a spare line if we earlier shrank the upper
window.

So the only solution I can think of is to convey some information to
shrink_window_lowest_first, with the help of a buffer-local variable,
telling that a window showing that buffer should not be resized if it is
possible to resize another window instead.

martin

Message #60 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: <1291 <at> debbugs.gnu.org>, <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow	Completions
Date: Mon, 3 Nov 2008 08:56:24 -0800

>  > In sum, if *Completions* is visible during minibuffer 
>  > completion, then the minibuffer should take its window
>  > into account. If not, it need not worry about it.
> 
> Ever since 1999 this is handled by Gerd's shrink_window_lowest_first
> function.  That function takes lines from the window above the
> minibuffer window and IIUC currently doesn't even care about 
> fixed-size windows.  It certainly doesn't care about what _kind of
> buffer_ is displayed in that window.

OK, that describes what the status quo is and some background.

> Moreover, the code responsible for re-growing the window after
> the minibuffer is re-shrunk will grow the lowest window
> again and we'll be left with a spare line if we earlier 
> shrank the upper window.

Not really a problem for *Completions*, I think. It is a temporary display
anyway. And when the minibuffer becomes inactive, *Completions* should go away
anyway (I say should, because it does not always, but that is a different
story).

> So the only solution I can think of is to convey some information to
> shrink_window_lowest_first, with the help of a buffer-local variable,
> telling that a window showing that buffer should not be 
> resized if it is possible to resize another window instead.

Again, I can't speak much to the implementation - I don't see the big picture,
no doubt. But my suggestion would be, again, not to try to deal with this
particular minor bug by changing general things. I would think that the code
that grows the minbuffer could just check whether completion is in progress and
*Completions* is displayed, and if so grow *Completions* by the same amount
(modulo some limits).

This is a only minor bug. If a way can't be found to fix it that is
local/particular to the minibuffer + *Completions*, I'd say don't bother. We
certainly don't want to make things worse generally.

Anyway, thanks for looking into it, Martin. I know that things are sometimes not
as simple as they can seem from the outside.  - Drew

Message #65 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 1291 <at> debbugs.gnu.org
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow Completions
Date: Mon, 03 Nov 2008 14:34:48 -0500

> > So the only solution I can think of is to convey some information to
> > shrink_window_lowest_first, with the help of a buffer-local
> > variable, telling that a window showing that buffer should not be
> > resized if it is possible to resize another window instead.
>
> Again, I can't speak much to the implementation - I don't see the big
> picture, no doubt. But my suggestion would be, again, not to try to
> deal with this particular minor bug by changing general things. I
> would think that the code that grows the minbuffer could just check
> whether completion is in progress and *Completions* is displayed, and
> if so grow *Completions* by the same amount (modulo some limits).

We might be able to revisit this after the release.  The current
(tentative) plan is to introduce some kind of "window grouping" feature,
which will be needed for CEDET/ECB.  It's possible that window groups
can also be used to handle situations like this.

Message #72 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: "'martin rudalics'" <rudalics <at> gmx.at>, <1291 <at> debbugs.gnu.org>,
        <nuxdoors <at> cegetel.net>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow Completions
Date: Mon, 3 Nov 2008 12:05:09 -0800

> From: Chong Yidong Sent: Monday, November 03, 2008 11:35 AM
> > > So the only solution I can think of is to convey some 
> > > information to shrink_window_lowest_first, with the help of a
> > > buffer-local variable, telling that a window showing that buffer
> > > should not be resized if it is possible to resize another window
> > > instead.
> >
> > Again, I can't speak much to the implementation - I don't 
> > see the big picture, no doubt. But my suggestion would be, again,
> > not to try to deal with this particular minor bug by changing
> > general things. I would think that the code that grows the
> > minbuffer could just check whether completion is in progress and
> > *Completions* is displayed, and if so grow *Completions* by the
> > same amount (modulo some limits).
> 
> We might be able to revisit this after the release.  The current
> (tentative) plan is to introduce some kind of "window 
> grouping" feature, which will be needed for CEDET/ECB.  It's
> possible that window groups can also be used to handle situations
> like this.

Sounds reasonable. Thanks.

Message #77 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Drew Adams <drew.adams <at> oracle.com>, 1291 <at> debbugs.gnu.org
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow Completions
Date: Tue, 04 Nov 2008 08:36:26 +0100

> We might be able to revisit this after the release.  The current
> (tentative) plan is to introduce some kind of "window grouping" feature,
> which will be needed for CEDET/ECB.  It's possible that window groups
> can also be used to handle situations like this.

Meanwhile I checked in a fix to recompute `window-end' in
`Electric-pop-up-window'.

I suppose that was your intention in the first place?

martin

Message #82 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>,
        "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: <1291 <at> debbugs.gnu.org>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow Completions
Date: Tue, 4 Nov 2008 06:28:30 -0800

> From: martin rudalics Sent: Monday, November 03, 2008 11:36 PM
>  > We might be able to revisit this after the release.  The current
>  > (tentative) plan is to introduce some kind of "window 
>  > grouping" feature, which will be needed for CEDET/ECB.  It's 
>  > possible that window groups can also be used to handle
>  > situations like this.
> 
> Meanwhile I checked in a fix to recompute `window-end' in
> `Electric-pop-up-window'.
> 
> I suppose that was your intention in the first place?

Dunno if that is a question for Yidong or me. If not for me, ignore this. 

If for me, I don't understand the question, sorry. Can you elaborate: what is
the bug (behavior) in Electric-*? It seemed to DTRT here, but I might have
missed something. (I haven't looked at your fix.) Thx.

Message #87 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>, 1291 <at> debbugs.gnu.org
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow Completions
Date: Tue, 04 Nov 2008 17:48:43 +0100

>> Meanwhile I checked in a fix to recompute `window-end' in
>> `Electric-pop-up-window'.
>>
>> I suppose that was your intention in the first place?
>
> Dunno if that is a question for Yidong or me. If not for me, ignore this.

It was a question for Chong.

> If for me, I don't understand the question, sorry. Can you elaborate: what is
> the bug (behavior) in Electric-*? It seemed to DTRT here, but I might have
> missed something. (I haven't looked at your fix.) Thx.

You earlier said that "Actually, it's worse than before: cuts off more
of the candidates in *Completions*."  I tried to remedy that.

martin

Message #92 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Drew Adams <drew.adams <at> oracle.com>, 1291 <at> debbugs.gnu.org
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow Completions
Date: Tue, 04 Nov 2008 11:56:31 -0500

martin rudalics <rudalics <at> gmx.at> writes:

>> We might be able to revisit this after the release.  The current
>> (tentative) plan is to introduce some kind of "window grouping" feature,
>> which will be needed for CEDET/ECB.  It's possible that window groups
>> can also be used to handle situations like this.
>
> Meanwhile I checked in a fix to recompute `window-end' in
> `Electric-pop-up-window'.
>
> I suppose that was your intention in the first place?

Thank you.

Message #97 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>,
        <1291 <at> debbugs.gnu.org>
Subject: RE: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if grow mini, grow Completions
Date: Tue, 4 Nov 2008 09:00:43 -0800

> It was a question for Chong.
> 
> You earlier said that "Actually, it's worse than before: cuts off more
> of the candidates in *Completions*."  I tried to remedy that.

Got it. Thx.

Message #102 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1291: 23.0.60;   1) resize-mini-windows: customizable, 2)
 if grow mini,   grow Completions
Date: Wed, 05 Nov 2008 03:37:34 -0700

martin rudalics wrote:
>  > That is not to say that the minibuffer display can never override 
> whatever is
>  > decided for the *Completions* display, but it should not do so 
> gratuitously. It
>  > should take the *Completions* display into account.
> 
> Ideally, yes.  But, as I said before, we first need a mechanism that
> allows us to establish a connection between such windows and the
> minibuffer (we could try to fit a window to its buffer _after_ resizing
> the minibuffer, but it's obvious how fragile such a solution would be).

Isn't the connection already provided by minibuffer-scroll-window?

What seems to be missing is the ability to distinguish between the
buffer displayed by minibuffer-scroll-window (e.g. *Completions*) and
the "parent" buffer of the minibuffer, so that we can determine whether
they are different and thus minibuffer-scroll-window should be treated
specially.

>  > But I don't think this should be fixed in some general way, treating the
>  > *Completions* or minibuffer window in the same way as any other 
> window. If
>  > that's what you're suggesting wrt `window-size-fixed', then I think 
> that's
>  > probably not the best approach.
> 
> FAIK the *Completions* windows and the minibuffer are independent from
> each other.  So we have to find a mechanism to tell the window
> management part what to do.  Fixing window sizes in some "lax" fashion
> is one way to do that.

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #107 received at 1291 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: 1291 <at> debbugs.gnu.org
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Wed, 05 Nov 2008 13:52:45 +0100

>> Ideally, yes.  But, as I said before, we first need a mechanism that
>> allows us to establish a connection between such windows and the
>> minibuffer (we could try to fit a window to its buffer _after_ resizing
>> the minibuffer, but it's obvious how fragile such a solution would be).
>
> Isn't the connection already provided by minibuffer-scroll-window?

In some sense, yes.  But shrink_window_lowest_first concentrates on the
lowest window, disregarding anything else.  And generally we want to
shrink the lowest window; only when it's fit to its buffer we don't.

> What seems to be missing is the ability to distinguish between the
> buffer displayed by minibuffer-scroll-window (e.g. *Completions*) and
> the "parent" buffer of the minibuffer, so that we can determine whether
> they are different and thus minibuffer-scroll-window should be treated
> specially.

That's an additional complication, so it seems easier to make the
*Completions* buffer one that doesn't like its windows getting resized.

martin

Message #112 received at 1291-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: drew.adams <at> oracle.com
Cc: 1291-done <at> debbugs.gnu.org
Subject: Re: bug#1291: 23.0.60;	1) resize-mini-windows: customizable, 2) if
 grow mini, grow	Completions
Date: Thu, 25 Dec 2014 20:29:18 +0100

> 1. Variable `resize-mini-windows' should be a customizable option. It
> is obviously intended to be modified by users.

`resize-mini-windows' is an option in Emacs 25.1.

> 2.
> emacs -Q
> M-x load-library tmm
> M-x tmm-menubar
>
> You'll see that not all candidates in *Completions* are visible. This
> is true in spite of the fact that `tmm-menubar' calls
> Electric-pop-up-window' which correctly fits the *Completions* window
> to the buffer.

This has been fixed in Emacs 25.0.50.1.  Bug closed.

Thanks, martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.