Subject: bug#76617: completing-read should accept spaces in require-match nil mode

From: Drew Adams <[email-masked]>
Date: Fri, 2 May 2025 23:43:20 +0000

>   > > Perhaps SPC and ? should self-insert when they do not extend the
>   > > completion text at all.  Would that behavior be convenient?
> 
>   > Only when require-match is nil, IMHO.
> 
> To self-insert when REQUIRE-MATCH is nil seems like a good idea.
> 
> What about with other values of REQUIRE-MATCH, in the case where
> adding the character would result in a match match something in the
> completion list?
> 
> For instance, if the minibuffer contains `foo' and `foo?' is one
> of the completions, them typing ? twice could insert ?
> 
> And something similar for SPC.

IMO there should be _no_ such restrictions, conditional
or otherwise.

Printable/self-inserting chars should generally
self-insert (i.e., without C-q) during completion.
RET/C-m and TAB/C-i are reasonable exceptions
(especially given their history).  But even C-j should
self-insert.

`completing-read' is completely general.  We shouldn't
assume anything about what the set of required-match
completions might be at any time - any chars, any order,
etc.

A given `completing-read' _call_ can, if need be, impose
such a restriction by let-binding a relevant minibuffer
keymap.

It took decades to get `read-file-name' to allow SPC to
self-insert.  It's taken decades more for SPC and ? to
be taken seriously also for `completing-read' insertion.
Time to realize that `completing-read' candidates can
contain any chars.  By default, we should self-insert
all printable chars.

(One opinion.)