[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36745: 27.0.50; completing-read with require-match nil does not acce
bug#36745: 27.0.50; completing-read with require-match nil does not accept spaces
Sun, 21 Jul 2019 09:27:13 +0200
* Michael Heerdegen <address@hidden> [2019-07-21 01:41]:
> Jean Louis <firstname.lastname@example.org> 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
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
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:
and you will get
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
- but it does not allow space after first
- 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
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.
bug#36745: 27.0.50; completing-read with require-match nil does not accept spaces, Michael Heerdegen, 2019/07/20
bug#36745: 27.0.50; completing-read with require-match nil does not accept spaces, Basil L. Contovounesios, 2019/07/21
- bug#36745: 27.0.50; completing-read with require-match nil does not accept spaces,
Jean Louis <=