RE: [PATCH] Support "\n" in icomplete-separator

[Drew Adams <drew.adams@oracle.com>]

> Emacs's minibuffer input was not
> designed for showing too many completion candidates, let alone show
> them vertically arranged.  It was even less designed to display the
> candidates or other hints in overlays.

Maybe so.  What the creator originally had in mind was
designed in the terminal-only days, back in the Dark Ages.

I'd say too that minibuffer content and height is not
only about showing multiple completion candidates, i.e.,
what Ido, Icomplete, and similar do.

In my use, the minibuffer only shows one completion
candidate.  But that candidate can be multiple lines
of text.  Your point should be, I think, that it's
about the size of what is displayed in the minibuffer,
regardless of what is displayed there or how (text or
overlay, for example).

Your apparent assumption that the issue is only about
showing multiple candidates, and hence your comments
about implementing combo-boxes etc., may be warranted
in the context of only this thread, which is about
Icomplete.  But the general issue of minibuffer size
is, well more general.

In any case, I think that the Emacs minibuffer should
be able to handle pretty much arbitrary text, overlays,
etc. - just what other buffers can handle.  How such
things get displayed can be up to the code that handles
displaying it, and it need not be handled well by
vanilla Emacs by default.  But the minibuffer should
allow libraries and user code to handle large content.