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

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

[Drew Adams]

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'
 

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

[martin rudalics]

 > 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@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

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

[Drew Adams]

> From: martin rudalics Sent: Sunday, November 02, 2008 6:12 AM
> To: 1291@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@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!

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

[Drew Adams]

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

> 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@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

[-- Attachment #2: bug-tmm-menubar-electric.png --]
[-- Type: image/png, Size: 83254 bytes --]

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

[martin rudalics]

 > 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)))

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

[Drew Adams]

> 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'.

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

[martin rudalics]

 > 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

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

[Drew Adams]

> 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.

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

[martin rudalics]

 > 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

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

[Drew Adams]

> 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.

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

[martin rudalics]

 > 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

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

[Kevin Rodgers]

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

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

[martin rudalics]

 >> 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

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

[martin rudalics]

 > 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

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

[Chong Yidong]

> > 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.

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

[Drew Adams]

> 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.

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

[martin rudalics]

 > 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

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

[Drew Adams]

> 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.

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

[martin rudalics]

 >> 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

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

[Drew Adams]

> 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.

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

[Chong Yidong]

martin rudalics <rudalics@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.