Re: on helm substantial differences

[Juri Linkov]

> If I may comment on (not related to above paragraph) the attached .png
> picture is that minibuffer enlarged very much over the screen. What
> would happen if the screen would be split in two windows before
> completion, would then the very narrow scratch buffer on top be
> divided with another mode line? In that case both divided windows
> would be very narrow and not readable. Sometimes at least the focused
> window should be readable during completion as completion is very
> general for programmers who may need reference in the window they are
> working in.
>
> Large minibuffer window practically splits window in 2 parts, one very
> narrow, minibuffer very high. In this case your *scratch* buffer,
> would it have more text, would not be usable at all as it little would
> be visible.
>
> My suggestion is that minibuffer rather makes proper split window by
> default or that it does not enlarge over the screen more then
> the calculated half of the full window, as that way user would have
> visible buffer.
>
> My suggestion for Emacs that already has 2 split windows is that
> minibuffer completion does not resize the focused window as that is
> where user works and expects (probably) to maybe insert something into
> that buffer or use it as reference during completion. Rather
> minibuffer should use the unfocused other window (from two or more
> split windows) to show its completions then enlarging itself over the
> screen and effectively disturbing the visual static interface.

I suggested you to customize this easily by one-liner:

  (push '("\\`\\*Completions\\*\\'" nil (window-height)) display-buffer-alist)