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

[Jean Louis <bugs@gnu.support>]

* martin rudalics <rudalics@gmx.at> [2020-11-11 13:03]:
> >> Applications have to accept that users want their minibuffer windows to
> >> show just one line.  Or at most two lines.  Or three ...
> >
> > Also users: "Show us completions vertically" and
> > (setq <icomplete/ido/etc>-separator "\n")
> 
> Users shouldn't want the cake and eat it too.  Any application should
> take care of such users.  If an application has a truly expandable
> minibuffer window or a normal window at its hands, it can try to show
> completions vertically.  With the default minibuffer window, it should
> always behave as if only one line were available.

Personally, it is bad idea to expand minibuffer. I could agree maybe
to 2 lines, not even to three.

I prefer having possibility to expand completion into full screen and
to expand into split-window so that mode line remains where it is.

When I was asking here before some months how to write a function to
replace `read-from-minibuffer' into `read-from-buffer' I have got some
tips and I think Eli and others helped that Emacs does not break the
excursion. Then I made it possible for strings larger than length X to
expand editing into full window.

When there is string to be entered larger than what minibuffer should
accommodate in relation to legibility and disturbance of user
interface (mode line going up with longer strings), then the full
window opens and I can receive the string from window or full buffer.

There are various components of user interface, mini buffer is
"informational component" and users expect to get information on
familiar place.

Common user interface shall remain as such. Only exceptionally and by
user's CHOICE should minibuffer open up. Not by default.

Personally I like how helm does it, it opens split window usually and
mode line remains where it is, while I can use mini buffer to narrow
the collection and find the matches. I have not given any command to
helm to have my mode line jump up and down.

The built-in completing-read does not automatically let the mode line
jump up. I can complete with by using few words and TAB. If there is
no completion TAB will expand the mini buffer. In this case I have
explicitly decided to see the collection.

Deciding for user to expand mini buffer is bad idea. To understand my
feelings you would need to manage database by using completion
frameworks, with 100+ tables where some of them have hundreds of
thousands of records. If we already get split-screen, at least mode
line shall remain where it is.

What about the case of using minibuffer within minibuffer? I hope that
has been taken in account with icomplete.

Hide Enable Recursive Minibuffers: Toggle  on (non-nil)
    State : SET for current session only.
   Non-nil means to allow minibuffer commands while in the minibuffer. More

TAB is meant for line completion. For narrowing match completion there
are words and choice, up and down or forward and back. 

Maybe some lists of how to design user interfaces could help:
https://www.usability.gov/what-and-why/user-interface-design.html

What applies:

Quotes:

" Keep the interface simple. The best interfaces are almost invisible
to the user. They avoid unnecessary elements and are clear in the
language they use on labels and in messaging.  Create consistency and
use common UI elements. By using common elements in your UI, users
feel more comfortable and are able to get things done more quickly.
It is also important to create patterns in language, layout and design
throughout the site to help facilitate efficiency. Once a user learns
how to do something, they should be able to transfer that skill to
other parts of the site."

"Think about the defaults. By carefully thinking about and
anticipating the goals people bring to your site, you can create
defaults that reduce the burden on the user.  This becomes
particularly important when it comes to form design where you might
have an opportunity to have some fields pre-chosen or filled out."