bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: 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.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]