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

Previous Next

Package: emacs;

Reported by: Thierry Volpiatto <thievol <at> posteo.net>

Date: Mon, 30 Jun 2025 10:38:02 UTC

Severity: wishlist

Found in version 30.1

Full log


Message #32 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 17:32:55 +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 15:27:19 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > 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.
>
> Now I'm completely confused.  Let me step back and start over.

Sorry for the confusion.

> You started this discussion by describing some behavior of
> find-file-read-only that you thought was a bug, correct?

Not really a bug, but something unexpected I would say.

> If so, this discussion should lead to investigating why Emacs behaves
> like it does, and then to a decision whether and how to fix this
> behavior.
>
> Do you agree?

Yes.

> Or did I misunderstand your report and your rationale for starting
> this discussion?

Yes you misunderstood because I was not clear.

> If I understood you correctly, then I must see the problematic
> behavior in order to reason about it, let alone try to find out its
> reasons.  And I so far failed to see what you describe.  So I'm stuck
> trying to reproduce the problematic behavior you described, and would
> like to find a way of reproducing it before I could contribute
> something useful to this discussion.

Ok.

Start emacs -Q, say you have a directory ~/tmp/ containing foo.txt and
bar.txt.

1) C-x C-r ~/tmp/test.txt RET
=> find-file--read-only: ~/tmp/foo.txt does not exist

2) C-x C-r ~/tmp/*.txt RET
=> Two buffer are opened foo.txt and bar.txt.

That's fine for 1) but I would prefer a [no match] preventing exiting the
minibuffer.
For 2) I had expected a [confirm] before maybe blocking emacs by opening
too many buffers.

Now (setq confirm-nonexistent-file-or-buffer 'confirm)

And repeat 1) and 2).
As you can see in both case we have a minibuffer-message [confirm].

In 1) I think it is confusing, I had expected instead a [no match].

In 2) [confirm] is nice because it may prevent opening hundred of buffer
and blocking emacs.

So what I think would be the best is having [no match] in 1) and
[confirm] in 2), however with the tools we have under hand you can't
implement this, this is why find-file-read-only allow to have [confirm]
in 2) but must use some code exiting with error in 1), you can't
implement both, it is one or the other.

By patching completion--complete-and-exit (see the two patches I sent)
you can allow the REQUIRE-MATCH arg of completing read using a function
that can exit with three option: nil, non-nil or confirm whereas with
the current code you can exit with nil or non-nil only.

And then you can make find-file-read-only prevent exiting with a non
existing file in 1), And confirm a wildcard in 2).

Is this more clear?

Note:
As you can see this is an enhancement there is no bug, the current
behavior is not so nice but it is ok, we can live with it.

Thanks for reading and sorry for beeing unclear, it is not easy to
explain non trivial things in english.

-- 
Thierry




This bug report was last modified 37 days ago.

Previous Next


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