Re: completing-read does not accept spaces

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> Reading the docstring of completing-read I see no reason why it should
>> not accept spaces. So either the docstring is at fault or there is a bug
>> on completing-read. 
>
> No.  The doc to read is (elisp) `Completion Commands', in particular,
> about the variables named `minibuffer-local-*-map'.

This is terrible. completing-read docstring says

   Read a string in the minibuffer, with completion.

A string is a string is a string. It doesn't say "a word", or "a
symbol", or "a string without spaces". It says "a string".

>> Curiously, the function will complete the user's input to a string
>> containing spaces if there is one on the collection of candidates:
>> (completing-read "say: " (list "hello there"))
>
> Irrelevant here.  As the doc I mentioned says, `SPC' is bound to
> `minibuffer-complete-word', and that is what you are seeing.  `SPC' is
> not bound to `self-insert-command' here - it is not inserting itself.

So by not binding SPC to self-insert-command they are breaking
completing-read stated purpose.

> It is just completing a "word" at a time.
>
>> Please submit a bug report (M-x report-emacs-bug) against completing-read.
>
> No.  There is no bug here.  This is the behavior by design, like
> it or not.

The docstring is wrong when it says "Read a string". That's a bug, IMO.

> Do I personally think that `SPC' should generally be self-inserting
> during completion?  You bet I do.  And so should `?'.  And so should
> `C-j' (newline).  (And this is the case in Icicle mode, for instance.)
>
> But that is not the opinion of Emacs Dev.  It took decades to finally
> get `SPC' to be self-inserting for file-name completion (see variable
> `minibuffer-local-filename-completion-map', in the same Elisp manual
> node).  Patience. ;-)

Sigh. I know what you mean.