Subject: Re: bug#78926: 30.1; find-file-read-only require-match inconsistency

From: Thierry Volpiatto <[email-masked]>
Date: Tue, 01 Jul 2025 15:27:19 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: Thierry Volpiatto <[email-masked]>
>> Cc: Thierry Volpiatto <[email-masked]>,  [email-masked]
>> Date: Tue, 01 Jul 2025 14:16:53 +0000
>> 
>> Eli Zaretskii <[email-masked]> writes:
>> 
>> >> >   emacs -Q
>> >> >   M-x set-variable RET confirm-nonexistent-file-or-buffer RET nil RET
>> >> >   M-x find-file-read-only RET foobar RET
>> >> 
>> >> > and Emacs signaled an error saying that the file does not exist.
>> >> 
>> >> I meant with the default value of confirm-nonexistent-file-or-buffer.
>> >
>> > I see the same with the default value as well.
>> >
>> >> It's surprizing that after pressing RET I have a minibuffer-message
>> >> saying [confirm] and then when I hit RET again I have the error you
>> >> mentioned.
>> >
>> > I don't see any [confirm] when invoking find-file-read-only.  When I
>> > press RET, I see an error message:
>> >
>> >   /some/file/name does not exist
>> >
>> > So I guess something is still missing, which is why I asked for
>> > detailed instructions.  I suspect we still do something differently.
>> 
>> The require-match used there is 'confirm-after-completion so perhaps you
>> have to try to complete on something before RET? 
>
> I didn't try to complete at all.  I just typed a name of a
> non-existent file and pressed RET.

>> With Helm such require-match is always transformed in 'confirm.
>
> So you are not doing this in "emacs -Q", but after activating Helm?

Did both.

>> Please try with the patch applied and without to see the difference and
>> perhaps what I mean.
>
> Sorry, I don't understand why I need to patch Emacs in order to see
> some behavior it has by default.

To better understand my poor explanations :-)

But emacs doesn't have this behavior by default.

-- 
Thierry