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

[Jean Louis <bugs@gnu.support>]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-11-11 12:08]:
> 
> > > And here I come to the answer to your question: for me, the bug here
> > > is that the prompt is hidden in favor of the overlay text.
> > 
> > Applications have to accept that users want their mini-buffer windows to
> > show just one line.  Or at most two lines.  Or three ...
> > 
> 
> I agree with you, except that I would not write "users want" but "some users
> want".
> 
> At the same time, applications should be given the possibility to override
> the current only behavior, which starts displaying at the beginning of the
> minibuffer line on which the cursor is.  Applications should have the
> possibility to give a hint to redisplay that, when it is possible (that is,
> when users have not asked for a single line minibuffer for example)
> displaying should start at the beginning of the minibuffer (= point-min).

In relation to this last line above "displaying should start..." I do
not agree to that detail. This may also apply to other completion
packages within or outside Emacs.

Normally when minibuffer is opened there can be some default and user
decides if to complete or not.

To put a possible match in the space where I have my input is
capricious choice where user did not decide about it. I am sorry that
I present maybe too many disagreements, it is not meant like
that. This is only for thinking.

I do not want as user for program to give me matches into space where
I need to press enter to choose that match. If that is taking place
then description for icomplete, ido, fido should tell that to user.

Built-in completion gives me some default in the line (maybe), but it
does not enter random match into the minibuffer. So as user I do not
want random matches already in my minibuffer. That seams wrong. I did
not even start typing.

M-x (Here I can enter what I want)

As if I did not start typing why it is completing? That is
hypothetical question.

Built-in `completing-read' does not complete for me if I as user do
not want. I have to decide to press TAB to get completion. Not one
time, I have to decide normally 2 times. So it is very explicit
completion that does not disturb user.

Any completing package should not coerce user with matches. It shall
by default leave to the user option to write in the minibuffer what
user wants. This may not match, but user shall be left free to write.

M-x icomplete-mode

"Icomplete mode disabled"

C-x C-f (no completion shown, just some default) and I can write what
I want, only if I press TAB two times I can complete.

M-x icomplete-mode

"Icomplete mode enabled"

C-x C-f shows BUNCH OF UNRELATED FILES that I have not choosen neither
wanted to be shown in my minibuffer. Minibuffer is disturbed and mode
line jumps up.

M-x helm-find-file

Window splits

Minibuffer says:

Find files or url: /home/data1/protected/tmp

and I can write anything in the minibuffer. Program does not coerce me
with files not related to my choice on the place where I should maybe
press enter.

That this is dangerous have been shown in bug report where files can
be accidentally deleted when using ido-mode.