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: Mon, 18 Dec 2023 21:52:33 -0500 Message-ID: <87il4uvoob.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> <87ttr7nzyj.fsf@breatheoutbreathe.in> <83pm1u6f8l.fsf@gnu.org> <83fs2o2wb0.fsf@gnu.org> <83v8bj2794.fsf@gnu.org> <83r0m70zwp.fsf@gnu.org> <83sf6mzcz6.fsf@gnu.org> <878r72odzs.fsf@breatheoutbreathe.in> 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="15052"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, Eli Zaretskii , philipk@posteo.net, 66187@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 19 04:48:18 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 1rFR5a-0003c4-Te for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Dec 2023 04:48:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFR5M-0007U0-S4; Mon, 18 Dec 2023 22:48:00 -0500 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 1rFR5L-0007Tm-NK for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2023 22:47:59 -0500 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 1rFR5L-0001m6-FQ for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2023 22:47:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rFR5N-0000PX-Oc for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2023 22:48:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Joseph Turner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Dec 2023 03:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66187 X-GNU-PR-Package: emacs Original-Received: via spool by 66187-submit@debbugs.gnu.org id=B66187.17029576641433 (code B ref 66187); Tue, 19 Dec 2023 03:48:01 +0000 Original-Received: (at 66187) by debbugs.gnu.org; 19 Dec 2023 03:47:44 +0000 Original-Received: from localhost ([127.0.0.1]:33911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rFR55-0000Mz-La for submit@debbugs.gnu.org; Mon, 18 Dec 2023 22:47:44 -0500 Original-Received: from out-171.mta1.migadu.com ([2001:41d0:203:375::ab]:62634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rFR53-0000MQ-7H for 66187@debbugs.gnu.org; Mon, 18 Dec 2023 22:47:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breatheoutbreathe.in; s=key1; t=1702957657; 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=cfd3LfPARVhLHBL6EvmE36/zpxCsRjk9M5lVnbx1s34=; b=WWcJQvUd4YtEHABiLDjhCDb8KBgOqhlTJwQ7zVY5w4XXdoKd/xOOx8i0XX5EOc29/UTItF 9du2hD6bnnX3x/ZMbIUP7/qs66iQtMBexMsQAlzXfRbtMFPTmbuAF/c8Vyw4C7E7KvNr68 HcsU3gEvywyu70T7SdYeNal0Dnl2dUc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-reply-to: X-Migadu-Flow: FLOW_OUT 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:276499 Archived-At: --=-=-= Content-Type: text/plain Hello! For reference, here's the little snippet I'm testing with: (completing-read "Prompt: " '("a" "b") nil (lambda (input) (string= "a" input))) where the only expected valid input is "a". Stefan Monnier writes: >> Here's another potential solution. While the attached patch seems to >> work, I'm not sure that minibuffer-completion-confirm should be checked >> in completion--do-completion instead of completion--complete-and-exit. > > It's definitely better to check it in `completion--complete-and-exit` > (which is about exiting and thus related to whether the content is > acceptable) than in `completion--do-completion` (which is just about > completion). I'm still not sure `completion--complete-and-exit' is the best place to check that input is valid before exiting. `completion--do-completion' contains the following cond clause, which prevents the user from exiting with, e.g., "c". ((null comp) (minibuffer-hide-completions) (unless completion-fail-discreetly (ding) (completion--message "No match")) (minibuffer--bitset nil nil nil)) Perhaps we should also run that same body when REQUIRE-MATCH is a function which returns nil? > The patch looks OK, thanks. We could make it call `completion-function` > instead of saying "no match" (after all, it has "complete" in its name), > but it comes with its own set of problems. If I understand correctly, the attached patch does this. I think this works inside of `completion-complete-and-exit', but maybe not inside of `minibuffer-force-complete-and-exit' since the former calls `completion--do-completion' internally but the latter does not. Still exploring ideas... Thanks! Joseph --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Fix-completing-read-functional-REQUIRE-MATCH-behavio-2.patch >From 7b779782504a7b94f64f100a1f8bb71c483873e5 Mon Sep 17 00:00:00 2001 From: Joseph Turner Date: Mon, 18 Dec 2023 22:41:24 -0500 Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior * lisp/minibuffer.el (completion--do-completion): Refuse to exit minibuffer when REQUIRE-MATCH is a function which returns nil. (completion--complete-and-exit): Delegate handling of functional REQUIRE-MATCH to completion-function. See bug#66187. --- lisp/minibuffer.el | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 5c12d9fc914..5d26ff2423e 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1408,7 +1408,11 @@ when the buffer's text is already an exact match." (- (point) beg) md))) (cond - ((null comp) + ((or (null comp) + (and (eq t comp) + (functionp minibuffer-completion-confirm) + (not (funcall minibuffer-completion-confirm + (buffer-substring beg end))))) (minibuffer-hide-completions) (unless completion-fail-discreetly (ding) @@ -1849,10 +1853,8 @@ appear to be a match." ;; Allow user to specify null string ((= beg end) (funcall exit-function)) ;; The CONFIRM argument is a predicate. - ((and (functionp minibuffer-completion-confirm) - (funcall minibuffer-completion-confirm - (buffer-substring beg end))) - (funcall exit-function)) + ((functionp minibuffer-completion-confirm) + (funcall completion-function)) ;; See if we have a completion from the table. ((test-completion (buffer-substring beg end) minibuffer-completion-table -- 2.41.0 --=-=-=--