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

Previous Next

Full log

Message #17 received at 78926 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#78926: 30.1; find-file-read-only require-match inconsistency
Date: Tue, 01 Jul 2025 14:16:53 +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 12:38:12 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Thierry Volpiatto <thievol <at> posteo.net>
>> >> Date: Mon, 30 Jun 2025 10:36:29 +0000
>> >> 
>> >> find-file-read-only is allowing confirmation to exit with a non existing
>> >> file with `confirm-nonexistent-file-or-buffer`, but when the
>> >> filename is selected it calls `find-file--read-only` which itself prevent
>> >> exiting with a non existing file.
>> >> 
>> >> Did I miss something or is it a bug?
>> >
>> > Sorry, could you please elaborate?  What exactly did you do and what
>> > did you see?
>> >
>> > I tried:
>> >
>> >   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? 

With Helm such require-match is always transformed in 'confirm.

Note that the behavior of 'confirm-after-completion is difficult to
understand because you have to try to complete on something that doesn't
exist to after exit with it, confusing.

Please try with the patch applied and without to see the difference and
perhaps what I mean.

Thanks.

-- 
Thierry

Previous Next

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