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