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

[Drew Adams]

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

Sure, unless they tell users what the behavior is
and users choose to use them, i.e., choose that
behavior.  An "application" can present choices to
users just as much as a user option can.

The function `customize-save-variable' is an
"application" that a user can use to change, i.e.,
override an option setting.  What makes it OK is
that the command tells you what it does, and it's
up to use whether you use it.

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

Good to hear.  But why the restrictions for non-standalone?

What I said about Icicles is independent of a standalone
minibuffer frame.  There are lots of situations under which
minibuffer content can reasonably be more than a line or two.

I don't see any good reason presented for such restrictions.