bug#36745: 27.0.50; completing-read with require-match nil does not accept spaces

[Jean Louis <bugs@gnu.support>]

* Michael Heerdegen <michael_heerdegen@web.de> [2019-07-21 01:41]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I think that it is not logical if it says any input that spaces
> > cannot be entered and it is in that sense possible bug.
> 
> I think you should read it as any (given) input
> string (is accepted).

That is why it is bug. Either it has to be
documented in the function documentation or it
should be "any". One of those.

> So I don't see any bug in the strict sense.  OTOH I think it would be
> good to speak out that SPC is special, and mention the C-q SPC
> workaround, at least in the manual (if we don't do this already - do
> we?).

I see that it is documented for SPC to be
completion of the word. And I think if many people
are used to it, then SPC cannot be used as SPC.

There is option to change the completion key map
so users who can program they can do it easily,
and I am fine too.

I think function shall be described better with at
least some reference within the function
description to the minibuffer-local-completion-map
for example as I found it there that SPC does
minibuffer-complete-word

However, logic is missing and function is in that
sense also not doing it as promised:

(let ((completion-ignore-case t))
  (completing-read "Choice: " '("EXPENSES LIST" "WORK") nil nil))

Now do this:

expSPCsomethingENTER

and you will get

"EXPENSES something"

So I can add the word with spaces to those words
which already exist.

But I cannot enter first unknown word with space
and I get message [no match].

The message [no match] disappears after some time.

Maybe it would be logical to enter the space
before this message appears and then to say [no
match] in the same manner.

I think space shall be allowed in that sense and
in that particular situation when require-match is
nil to allow "any input":

- for reason that it does allow space after first
  matching word

- but it does not allow space after first
  non-matching word

- and it would not hurt any body that space is
  added after first non-matching word after the
  message [no match] have been shown

- as it is logical if there is no match, but user
  can enter any input, to allow the user to enter
  space

and in that sense the
minibuffer-local-completion-map need not be
changed at all

The only change would be that after after first
non-matching word if space is used, the space is
added even though completion did not match.

Jean