GNU bug report logs - #78926
30.1; find-file-read-only require-match inconsistency

Previous Next

Full log

View this message in rfc822 format

From: Thierry Volpiatto <thievol <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Thierry Volpiatto <thievol <at> posteo.net>, 78926 <at> debbugs.gnu.org
Subject: bug#78926: 30.1; find-file-read-only require-match inconsistency
Date: Tue, 01 Jul 2025 15:27:19 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thievol <at> posteo.net>
>> Cc: Thierry Volpiatto <thievol <at> posteo.net>,  78926 <at> debbugs.gnu.org
>> Date: Tue, 01 Jul 2025 14:16:53 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.