Re: feature/icomplete-vertical

[martin rudalics]

> Just calculating the window dimensions is already a nontrivial
> task. There are two cases: a miniwindow-only frame, and the "normal"
> case.  In the first case you need to use frame-height, and multiply it
> with the pixel height of the "default" face.  In the second case you
> can get the maximal dimensions with max-mini-window-height, and
> multiply it by the pixel height of the "default" face.  But you cannot
> just multiply max-mini-window-height by that height, that would be too
> easy.  There are again two cases: either max-mini-window-height is an
> integer, in which case you can just do that multiplication, or it is a
> floating point number, in which case you have to multiply that number
> by frame-height and truncate it, and multiply the resulting number by
> the pixel height of the "default" face...

You underestimate the complexity of resizing the minibuffer window.
'max-mini-window-height' and, say 'frame-pixel-height', are by no means
sufficient to determine whether the minibuffer window can be really made
that large.  You have to check whether the remaining windows on the same
frame can be made sufficiently small in order to accommodate the
enlarged minibuffer window, including the case where you have
fixed-height or height-preserved windows.  Look at the code of
'window--resize-mini-window' and 'window--resize-root-window-vertically'
to see how this can be done.  And even if your code works, you may have
modified the start positions of many other windows on the same frame
when the minibuffer window shrinks back.

I'd never use the default minibuffer window for displaying larger lists
of vertically arranged objects.  On GUIs use a separate child frame, on
TTYs a side window instead.

martin