From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.bugs Subject: bug#36745: 27.0.50; completing-read with require-match nil does not accept spaces Date: Sun, 21 Jul 2019 09:27:13 +0200 Message-ID: <20190721072713.GA13058@protected.rcdrun.com> References: <86blxoil4q.fsf@protected.rcdrun.com> <87o91oxojr.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="70675"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 36745@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 21 09:28:09 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hp6GP-000IHb-BO for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jul 2019 09:28:09 +0200 Original-Received: from localhost ([::1]:54902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hp6GN-0005Je-P3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jul 2019 03:28:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43724) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hp6GK-0005JW-Pd for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2019 03:28:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hp6GI-0000Tp-O8 for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2019 03:28:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49278) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hp6GI-0000TG-Jn for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2019 03:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hp6GI-0005XG-Eu for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2019 03:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jean Louis Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Jul 2019 07:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36745 X-GNU-PR-Package: emacs Original-Received: via spool by 36745-submit@debbugs.gnu.org id=B36745.156369404721238 (code B ref 36745); Sun, 21 Jul 2019 07:28:02 +0000 Original-Received: (at 36745) by debbugs.gnu.org; 21 Jul 2019 07:27:27 +0000 Original-Received: from localhost ([127.0.0.1]:58099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hp6Fj-0005WU-5o for submit@debbugs.gnu.org; Sun, 21 Jul 2019 03:27:27 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:37713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hp6Fh-0005WE-N6 for 36745@debbugs.gnu.org; Sun, 21 Jul 2019 03:27:26 -0400 Original-Received: from protected.rcdrun.com (localhost [::1]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA; Sun, 21 Jul 2019 00:27:19 -0700 id 000000000002034C.000000005D3413D7.000078B5 Original-Received: from localhost (protected.rcdrun.com [local]) by protected.rcdrun.com (OpenSMTPD) with ESMTPA id b0b6579d; Sun, 21 Jul 2019 07:27:15 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87o91oxojr.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:163505 Archived-At: * Michael Heerdegen [2019-07-21 01:41]: > Jean Louis 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