From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function Date: Tue, 03 Oct 2023 14:18:42 -0700 Message-ID: <87ttr7nzyj.fsf@breatheoutbreathe.in> References: <87r0mni6m1.fsf@breatheoutbreathe.in> <87bkdq3nw6.fsf@web.de> <875y3yx221.fsf@breatheoutbreathe.in> <87pm260wh9.fsf@web.de> <87v8bx48ww.fsf@breatheoutbreathe.in> <87msx8sbpv.fsf@web.de> <87bkdoh1gy.fsf@breatheoutbreathe.in> <87h6ngs85e.fsf@web.de> Reply-To: Joseph Turner Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34928"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, 66187@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 03 23:44:59 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qnnCN-0008qv-2n for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Oct 2023 23:44:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnnCA-0000El-RV; Tue, 03 Oct 2023 17:44:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnnC9-0000ER-3U for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2023 17:44:45 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qnnC8-0000jc-Rp for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2023 17:44:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qnnCP-00073W-Sg for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2023 17:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Joseph Turner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Oct 2023 21:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66187 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: Philip Kaludercic , "Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors" , 66187@debbugs.gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.169636949527091 (code B ref -1); Tue, 03 Oct 2023 21:45:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Oct 2023 21:44:55 +0000 Original-Received: from localhost ([127.0.0.1]:40838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnnCI-00072r-Ii for submit@debbugs.gnu.org; Tue, 03 Oct 2023 17:44:55 -0400 Original-Received: from lists.gnu.org ([2001:470:142::17]:58342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnnCG-00072f-Sv for submit@debbugs.gnu.org; Tue, 03 Oct 2023 17:44:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnnBt-0000Cd-3E for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2023 17:44:29 -0400 Original-Received: from out-208.mta1.migadu.com ([95.215.58.208]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnnBq-0000RH-9t for bug-gnu-emacs@gnu.org; Tue, 03 Oct 2023 17:44:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breatheoutbreathe.in; s=key1; t=1696369464; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2M8CtT3MSfavIDkfw4MlLIMBbB/avU+mP6n6hgt7NoI=; b=IjLTtpaANqEmI7a3bXLFSCl+xfNosP1VIUSVVVXpIGolbZ9QOwQBZaomIC3K+kr+77Z3Ak 8cTeB+At6O6Dix+j1aPPPFjp/tROCmKh2rhUyOcCbEIn8pDtIZziOUDx4PgSW4a/Y9vp/O /TFR8qZesIfyAwNObw0sM9pnI0kEMjs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-reply-to: <87h6ngs85e.fsf@web.de> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=95.215.58.208; envelope-from=joseph@breatheoutbreathe.in; helo=out-208.mta1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271742 Archived-At: --=-=-= Content-Type: text/plain Michael Heerdegen writes: > I had a look and tried this: > > [2. text/x-diff; 0001-WIP-Bug-66187.patch] > From ad895d2df5c69e015c2c7eba5116ab2d440e1fbc Mon Sep 17 00:00:00 2001 > From: Michael Heerdegen > Date: Wed, 27 Sep 2023 03:32:37 +0200 > Subject: [PATCH] WIP: Bug#66187 > > --- > lisp/minibuffer.el | 29 +++++++++++++++-------------- > 1 file changed, 15 insertions(+), 14 deletions(-) > > diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el > index 2120e31775e..79a8786fbac 100644 > --- a/lisp/minibuffer.el > +++ b/lisp/minibuffer.el > @@ -3061,13 +3061,23 @@ completion-file-name-table > (funcall (or pred 'file-exists-p) string))) > > (t > - (let* ((name (file-name-nondirectory string)) > + (let* ((test-directory (lambda (s) > + (let ((len (length s))) > + (and (> len 0) (eq (aref s (1- len)) ?/))))) > + (should-complete > + (and pred > + (if (eq pred 'file-directory-p) > + test-directory > + (lambda (f) > + (or (funcall test-directory f) > + (funcall pred f)))))) > + (name (file-name-nondirectory string)) > (specdir (file-name-directory string)) > (realdir (or specdir default-directory))) > > (cond > ((null action) > - (let ((comp (file-name-completion name realdir pred))) > + (let ((comp (file-name-completion name realdir should-complete))) > (if (stringp comp) > (concat specdir comp) > comp))) > @@ -3078,18 +3088,9 @@ completion-file-name-table > ;; Check the predicate, if necessary. > (unless (memq pred '(nil file-exists-p)) > (let ((comp ()) > - (pred > - (if (eq pred 'file-directory-p) > - ;; Brute-force speed up for directory checking: > - ;; Discard strings which don't end in a slash. > - (lambda (s) > - (let ((len (length s))) > - (and (> len 0) (eq (aref s (1- len)) ?/)))) > - ;; Must do it the hard (and slow) way. > - pred))) > - (let ((default-directory (expand-file-name realdir))) > - (dolist (tem all) > - (if (funcall pred tem) (push tem comp)))) > + (default-directory (expand-file-name realdir))) > + (dolist (tem all) > + (if (funcall should-complete tem) (push tem comp))) > (setq all (nreverse comp)))) > > all)))))) > I thought this would make Emacs complete as you want. But: what files > should be shown when hitting TAB? I decided to show only matching > files, plus all directories (seems logical, since these may contain > matching files). > But that gives a bad user experience: When I tried this I thought it > would not work because completion did not accept an existing empty > directory. Then I saw that it actually was not empty. But it contained only > plain files, no subdirectories, and TAB displayed nothing. Quite confusing! I dug a little more and realized that the IMO unexpected behavior resides in completing-read itself. According to the completing-read docstring, its REQUIRE-MATCH argument can be - a function, which will be called with the input as the argument. If the function returns a non-nil value, the minibuffer is exited with that argument as the value. I incorrectly assumed that this function would prevent matching items inside COLLECTION for which the function returns nil. What it actually does it accept input which is not part of COLLECTION if the REQUIRE-MATCH function returns non-nil. IOW, it doesn't narrow the potential completion options; it widens them. For example, given: (completing-read "Prompt: " '("a" "b") nil (lambda (input) (string= "a" input))) I expected that the prompt would refuse to complete "b". I was wrong. Since completing-read is such a fundamental part of Emacs, I doubt it will be possible to change this behavior. What do you think about the attached patch to clarify the completing-read docstring? Thank you!! Joseph --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Clarify-completing-read-REQUIRE-MATCH-function-docst.patch >From 10fa6dd5c659bed2b818fb925445cab2cbbb5325 Mon Sep 17 00:00:00 2001 From: Joseph Turner Date: Tue, 3 Oct 2023 14:40:22 -0700 Subject: [PATCH] Clarify completing-read REQUIRE-MATCH function docstring * src/minibuf.c (Fcompleting_read): Explicitly note that REQUIRE-MATCH function does not narrow the completion candidates. --- src/minibuf.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/minibuf.c b/src/minibuf.c index 58adde1bf66..616be7091ee 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -1999,8 +1999,11 @@ REQUIRE-MATCH can take the following values: `minibuffer-complete' right before `minibuffer-complete-and-exit' and the input is not an element of COLLECTION. - a function, which will be called with the input as the - argument. If the function returns a non-nil value, the - minibuffer is exited with that argument as the value. + argument. If the function returns a non-nil value or if + the input is a member of COLLECTION, the minibuffer is + exited with that argument as the value. If the function + returns nil and the input is not a member of COLLECTION, + then the user is not allowed to exit. - anything else behaves like t except that typing RET does not exit if it does non-null completion. -- 2.41.0 --=-=-=--