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: Thu, 05 Oct 2023 22:55:49 -0700 Message-ID: <87il7kz2yu.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> Reply-To: Joseph Turner Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25389"; 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 Fri Oct 06 08:26:28 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 1qoeI7-0006OM-WE for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 06 Oct 2023 08:26:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qoeDa-0006ML-Iw; Fri, 06 Oct 2023 02:21:47 -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 1qoeDX-0006Ds-Rn for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2023 02:21:43 -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 1qoeDX-0003BG-Iw for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2023 02:21:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qoeDp-0003Qi-Ss for bug-gnu-emacs@gnu.org; Fri, 06 Oct 2023 02:22: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: Fri, 06 Oct 2023 06:22: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.169657326913102 (code B ref 66187); Fri, 06 Oct 2023 06:22:01 +0000 Original-Received: (at 66187) by debbugs.gnu.org; 6 Oct 2023 06:21:09 +0000 Original-Received: from localhost ([127.0.0.1]:49031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qoeCz-0003PF-9V for submit@debbugs.gnu.org; Fri, 06 Oct 2023 02:21:09 -0400 Original-Received: from out-210.mta1.migadu.com ([95.215.58.210]:12720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qoeCw-0003P5-LL for 66187@debbugs.gnu.org; Fri, 06 Oct 2023 02:21:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=breatheoutbreathe.in; s=key1; t=1696573246; 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=hor5wusk6RKL2ICsYRqfm/pw3eE5JESs3hQHSx00SPo=; b=E4pffs3ubEagSGVDcr64MfRLGLybPXR4sdtzC1Gtgo1XOPzroJSJzMuoB0Em/GHB2sxc4W ySXTAyUaPS+eE10Pv33g585u3OgD1ogzrVzkVhTpfwSHPYo6I1zFZUKVlYSUEHsT8vJJjG xjGz/gz3KD1EJoudG6L1/QDNtZJV7jg= 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:271928 Archived-At: Stefan Monnier writes: >>> 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? > > The use of a function as `require-match` is brand new in Emacs-29, so > I think it's not too late to fix it. I think rather than fixing the doc > we should fix the behavior, e.g. with the patch below. > > > Stefan > > > diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el > index 2120e31775e..d4da2d0d19b 100644 > --- a/lisp/minibuffer.el > +++ b/lisp/minibuffer.el > @@ -1835,15 +1835,13 @@ completion--complete-and-exit > (cond > ;; 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)) > ;; See if we have a completion from the table. > - ((test-completion (buffer-substring beg end) > - minibuffer-completion-table > - minibuffer-completion-predicate) > + ((if (functionp minibuffer-completion-confirm) > + (funcall minibuffer-completion-confirm > + (buffer-substring beg end)) > + (test-completion (buffer-substring beg end) > + minibuffer-completion-table > + minibuffer-completion-predicate)) > ;; FIXME: completion-ignore-case has various slightly > ;; incompatible meanings. E.g. it can reflect whether the user > ;; wants completion to pay attention to case, or whether the Thank you!! The above change fixes completion--complete-and-exit: attempting to exit with "b" now runs the final catchall cond clause. However, the unexpected behavior persists (it is possible to exit with "b") because the completion-function that completion-complete-and-exit passes to completion--complete-and-exit returns "b" anyway since "b" exactly matches one of elements of COLLECTION. Thank you! Joseph