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

[martin rudalics]

> Not sure what you mean by an application, but if the
> application is the thing that's presenting and reading
> the minibuffer then it's up to the application to
> decide how to present and use it, what to expect, and
> what to let users know about what to expect.
>
> There's no such rule/guideline, IMO, and none would
> be appropriate, to say that applications must accept
> that users (in general? always? all users? most?)
> want minibuffer windows to be of a certain shape/size,
> position, or whatever.

Users decide how large their frames are, how many windows they contain
and what the values of 'resize-mini-windows' and
'max-mini-window-height' are.  Applications that do not obey these
restrictions are wrong.

> My standalone minibuffer frame automatically fits
> itself to the minibuffer content, by default.
>
> And Icicles has commands that can provide large
> completion candidates, e.g., a complete sexp or a
> complete doc string.  And some such have more than a
> few lines.  And when you cycle among candidates the
> current candidate replaces the minibuffer content.
>
> So it's not so uncommon to have multiple-line
> content in the minibuffer.  There's nothing wrong
> with allowing such behavior.  I don't see why you're
> prescribing or supposing restrictions on the height
> of a minibuffer.  That's up to libraries and the
> users who decide to use them.

Standalone minibuffer frames are not subject to the restrictions cited
above.  Their size is constrained only by that of the display screen.

martin