emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66187: closed (read-file-name unexpected behavior when MUSTMATCH is


From: GNU bug Tracking System
Subject: bug#66187: closed (read-file-name unexpected behavior when MUSTMATCH is a function)
Date: Sun, 28 Jan 2024 19:32:02 +0000

Your message dated Sun, 28 Jan 2024 11:28:26 -0800
with message-id <87cytlqmqh.fsf@breatheoutbreathe.in>
and subject line Re: bug#66187: read-file-name unexpected behavior when 
MUSTMATCH is a function
has caused the debbugs.gnu.org bug report #66187,
regarding read-file-name unexpected behavior when MUSTMATCH is a function
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
66187: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66187
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: read-file-name unexpected behavior when MUSTMATCH is a function Date: Sun, 24 Sep 2023 14:31:28 -0700
Hello!

When the MUSTMATCH argument to read-file-name is a function, I'd expect
to see a message like "[Match required]" when the function returns nil.

For example, I'd expect the following to never match:

(read-file-name "Prompt: " nil nil #'ignore)

The behavior of read-file-name is unspecified when a MUSTMATCH function
returns nil:

- 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.

Would someone kindly explain the intended behavior here?

This issue originally came up in this thread about package-vc-checkout:
https://yhetil.org/emacs-bugs/87v8bzi7iz.fsf@breatheoutbreathe.in/T/#m224de986dcc97f23e17386fb0dd2db4a513726bf

Thanks!

Joseph



--- End Message ---
--- Begin Message --- Subject: Re: bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function Date: Sun, 28 Jan 2024 11:28:26 -0800
Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Ping!  I hope a fix like this can be merged into Emacs 29 still :)
>
> Duh, I can't believe I left you waiting for so long, this is awful.
> I just pushed this to `emacs-29`, thank you.
> I hope there might still be a next time, so I get a chance to do better.

It's all good!!  Life is happening :)

Thank you!!

Joseph

>
>         Stefan
>
>
>> From 609bf4964f88b01f4843e29b2cf71ee1cd2f6125 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Sun, 12 Nov 2023 13:21:50 -0800
>> Subject: [PATCH] Fix completing-read functional REQUIRE-MATCH behavior
>>
>> * lisp/minibuffer.el (completion--complete-and-exit): If
>> minibuffer-completion-confirm is a function which returns nil,
>> immediately fail to complete.
>>
>> See bug#66187.
>> ---
>>  lisp/minibuffer.el | 11 +++++++----
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>> index 3e30b68d5e9..9fad3e71fad 100644
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -1847,10 +1847,13 @@ 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)
>> +    (if (funcall minibuffer-completion-confirm
>> +                 (buffer-substring beg end))
>> +        (funcall exit-function)
>> +      (unless completion-fail-discreetly
>> +    (ding)
>> +    (completion--message "No match"))))
>>     ;; See if we have a completion from the table.
>>     ((test-completion (buffer-substring beg end)
>>                       minibuffer-completion-table



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]