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

From: Thierry Volpiatto <[email-masked]>
Date: Tue, 01 Jul 2025 17:32:55 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: Thierry Volpiatto <[email-masked]>
>> Cc: Thierry Volpiatto <[email-masked]>,  [email-masked]
>> Date: Tue, 01 Jul 2025 15:27:19 +0000
>> 
>> Eli Zaretskii <[email-masked]> 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