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

[martin rudalics]

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

With one subtle distinction: If an application tells me that in order to
get a better user experience I should customize a variable in a certain
way, I usually trust it.  I will trust it even more, if it supports my
own previously customized value.  But I don't trust an application that
tells me that in order to get a better user experience it will make the
customizations for me.

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

I tacitly assume that standalone minibuffer management obeys any
customization of the option 'resize-mini-frames' instead.

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

The default minibuffer windows work well under fair use.  Displaying a
few lines of text is OK.  Using a quarter of a frame's height can be
already troublesome, in particular with small windows present at the
frame's bottom.

martin