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

Previous Next

To reply to this bug, email your comments to 78926 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Thierry Volpiatto <thievol <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; find-file-read-only require-match inconsistency
Date: Mon, 30 Jun 2025 10:36:29 +0000

Hello,

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?

Thanks.


In GNU Emacs 30.1 (build 6, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2025-05-29 built on IPad-S340
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Linux Mint 21.3

Configured using:
 'configure CFLAGS=-O8 --bindir=/usr/local/sbin/emacs-30.1 --with-cairo
 --with-x-toolkit=lucid --with-modules --without-tree-sitter
 --without-native-compilation --disable-gc-mark-trace'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: 

Minor modes in effect:
  bug-reference-prog-mode: t
  server-mode: t
  psession-mode: t
  psession-savehist-mode: t
  global-git-gutter-mode: t
  git-gutter-mode: t
  display-time-mode: t
  winner-mode: t
  tv-save-place-mode: t
  helm-epa-mode: t
  helm-descbinds-mode: t
  helm-top-poll-mode: t
  helm-adaptive-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-ff-icon-mode: t
  helm-popup-tip-mode: t
  dired-async-mode: t
  minibuffer-depth-indicate-mode: t
  gcmh-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort epa-mail mail-extr gnus-msg emacsbug tramp-sh shortdoc
comp-common char-fold tramp-archive tramp-gvfs tramp-cache time-stamp
zeroconf helm-command helm-elisp helm-eval edebug debug backtrace
helm-info helm-ls-git vc-git vc vc-dispatcher cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs make-mode
markdown-mode color oc-basic cl-extra org-element org-persist org-id
org-refile org-element-ast inline avl-tree generator ol-eww eww
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range gnus-win gnus nnheader range ol-docview
doc-view ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi org-config
ob-gnuplot org-crypt org-protocol org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete org-list
org-footnote org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold
org-fold-core org-keys oc org-loaddefs org-compat org-macs flycheck
find-func sh-script smie treesit executable jka-compr bug-reference
thingatpt cus-start naquadah-tv-theme view mule-util solar cal-dst
holidays holiday-loaddefs appt diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs server imenu tv-utils psession frameset
mail-config gnus-patch diff-mode track-changes addressbook-bookmark
message sendmail yank-media puny rfc822 mml mml-sec gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
bookmark git-gutter pcase avoid dired-extension time winner
describe-variable help-fns radix-tree tv-save-place.el init-helm epa
derived epg rfc6068 epg-config helm-epa helm-descbinds cus-edit pp
cus-load wid-edit helm-sys helm-adaptive helm-mode helm-misc helm-files
image-dired image-dired-tags image-dired-external image-dired-util
image-mode exif filenotify tramp rx trampver tramp-integration files-x
tramp-message help-mode tramp-compat xdg shell pcomplete parse-time
iso8601 time-date tramp-loaddefs helm-buffers helm-x-icons all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons helm-occur helm-tags
helm-locate helm-grep wgrep-helm wgrep grep compile text-property-search
comint ansi-osc ring helm-regexp format-spec ansi-color helm-utils
helm-help helm-types helm-extensions-autoloads helm-autoloads helm
helm-global-bindings helm-easymenu edmacro kmacro helm-core helm-source
helm-multi-match helm-lib dired-async async dired-aux dired
dired-loaddefs isl-autoloads mb-depth gcmh easy-mmode
all-the-icons-autoloads bash-completion-autoloads emms-autoloads
flycheck-autoloads info ledger-mode-autoloads markdown-mode-autoloads
nerd-icons-autoloads w3m-load w3m-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process emacs)

Memory information:
((conses 16 689730 616604) (symbols 48 37339 2)
 (strings 32 197873 47275) (string-bytes 1 5419858) (vectors 16 73920)
 (vector-slots 8 1155980 212667) (floats 8 3119 1134)
 (intervals 56 14099 2420) (buffers 984 127))

-- 
Thierry

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

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

> 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.
Sounds like Emacs does behave reasonably.

Message #11 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 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.
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.
It would be better to use a [no match] message preventing exiting
minibuffer in such case, however if you do this (i.e. require-match ==
t) you prevent exiting with a wildcard. I tried this patch that work as
I expect (which is maybe not what you or others expect):

    index 04a212b9bca..8cb93c90351 100644
    --- a/lisp/files.el
    +++ b/lisp/files.el
    @@ -2072,23 +2072,28 @@ file names with wildcards."
          (current-buffer)))
     
     (defun find-file--read-only (fun filename wildcards)
    -  (unless (or (and wildcards find-file-wildcards
    -		   (not (file-name-quoted-p filename))
    -		   (string-match "[[*?]" filename))
    -	      (file-exists-p filename))
    -    (error "%s does not exist" filename))
    +  ;; On interactive calls WILDCARDS is always non nil. 
    +  (let ((find-file-wildcards (and wildcards find-file-wildcards)))
    +    (unless (find-file--read-only-require-match filename)
    +      (error "%s does not exist" filename)))
       (let ((value (funcall fun filename wildcards)))
         (mapc (lambda (b) (with-current-buffer b (read-only-mode 1)))
     	  (if (listp value) value (list value)))
         value))
     
    +(defun find-file--read-only-require-match (input)
    +  (or (and find-file-wildcards
    +           (not (file-name-quoted-p input))
    +	   (string-match "[[*?]" input))
    +      (file-exists-p input)))
    +
     (defun find-file-read-only (filename &optional wildcards)
       "Edit file FILENAME but don't allow changes.
     Like \\[find-file], but marks buffer as read-only.
     Use \\[read-only-mode] to permit editing."
       (interactive
        (find-file-read-args "Find file read-only: "
    -                        (confirm-nonexistent-file-or-buffer)))
    +                        #'find-file--read-only-require-match))
       (find-file--read-only #'find-file filename wildcards))
     
     (defun find-file-read-only-other-window (filename &optional wildcards)

The problem is that this patch doesn't ask anymore for confirmation when
input is a wildcard, perhaps a new feature would be to enhance the
behavior of require-match used as a function.  Currently the function
can either return nil or t, it could return in addition 'confirm and
in this case send a minibuffer message [confirm], on next RET hit it
would exit.

-- 
Thierry

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

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

> 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.

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

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

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

> 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?

> 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.

Message #23 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 15:13:48 +0000

[Message part 1 (text/plain, inline)]

I modified `completion--complete-and-exit` so that the REQUIRE-MATCH
argument used with a function as value allows this function to exit with
'confirm in addition of nil/non-nil.

I then modified find-file-read-only so that it takes advantage of this:
- If you enter a wilcard you are now asked for confirm.
- If you enter a non existing filename you can't exit ([nomatch].

Note:
Of course the current behavior of find-file-read-only is fine, maybe a
little confusing but it's ok, this patch is just a proof of concept for
REQUIRE-MATCH used as a function with this new behavior.

The patches need to be reworked, didn't fully test the non interactive
usage and nothing is documented, particularly REQUIRE-MATCH in
completing-read, need also you commentaries because I guess not all the
corner cases are completed.

Thanks.

-- 
Thierry

[0001-Allow-require-match-as-a-function-to-return-confirm.patch (text/x-diff, attachment)]

[0002-Make-find-file-read-only-ask-for-confirmation-or.patch (text/x-diff, attachment)]

Message #26 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 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

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

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

> 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.

You started this discussion by describing some behavior of
find-file-read-only that you thought was a bug, correct?  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?  Or did I misunderstand your report and your rationale
for starting this discussion?

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.

Sorry for being so dense.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: 78926 <at> debbugs.gnu.org
Subject: Re: bug#78926: 30.1; find-file-read-only require-match inconsistency
Date: Wed, 02 Jul 2025 14:12:08 +0300

severity 78926 wishlist
thanks

> From: Thierry Volpiatto <thievol <at> posteo.net>
> Cc: Thierry Volpiatto <thievol <at> posteo.net>,  78926 <at> debbugs.gnu.org
> Date: Tue, 01 Jul 2025 17:32:55 +0000
> 
> 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.

find-file and friends are specially programmed not to do that, because
otherwise creating new files, a very frequent operation, would be too
annoying.  So I think this is a reasonable behavior.

> For 2) I had expected a [confirm] before maybe blocking emacs by opening
> too many buffers.

We have find-file-wildcards to control this.  AFAIU, you would like to
extend that variable to accept an integer value, which means visit
only up to that number of files, otherwise ask for confirmation.
Patches welcome.

> 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].

Not sure why.  "No match" comes from completion, whereas "confirm"
comes from the coder that is controlled by the variable you
customized.  Not sure why you prefer "no match", since it's much more
general and therefore potentially confusing, especially for non-native
English speakers.

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

I'd argue that it might be a bug.  Why ask for confirmation in this
case?

> 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?

Yes, thanks.

> 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.

Agree.

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

No need to be sorry, and thanks.

Message #40 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: Thu, 03 Jul 2025 04:16:53 +0000

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

> severity 78926 wishlist
> thanks
>
>> From: Thierry Volpiatto <thievol <at> posteo.net>
>> Cc: Thierry Volpiatto <thievol <at> posteo.net>,  78926 <at> debbugs.gnu.org
>> Date: Tue, 01 Jul 2025 17:32:55 +0000
>> 
>> 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.
>
> find-file and friends are specially programmed not to do that, because
> otherwise creating new files, a very frequent operation, would be too
> annoying.

find-file and variants yes, but not find-file-read-only which is
programmed to not create new file, this is why I took this example.
Having the ability to use for one completing-read three options for
REQUIRE-MATCH instead of only two is what I would like to intoduce.  The
way find-file-read-only is implemented currently is because this feature
is missing.

> So I think this is a reasonable behavior.

>> For 2) I had expected a [confirm] before maybe blocking emacs by opening
>> too many buffers.
>
> We have find-file-wildcards to control this.  AFAIU, you would like to
> extend that variable to accept an integer value, which means visit
> only up to that number of files, otherwise ask for confirmation.

It is not what I want, but yes it is a good idea.

> Patches welcome.
>
>> 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].
>
> Not sure why.  "No match" comes from completion, whereas "confirm"
> comes from the coder that is controlled by the variable you
> customized.  Not sure why you prefer "no match", since it's much more
> general and therefore potentially confusing,

It is not confusing, it just prevent exiting with a not existing file
whereas the current code allows exiting and then send an error once done
which is confusing, but IIUC it has been implemented this way to provide
at the same time confirm-nonexistent-file-or-buffer and prevent creating
a new file, I am sure the author of this code would have used the
feature I propose if available.

> especially for non-native English speakers.
>
>> In 2) [confirm] is nice because it may prevent opening hundred of buffer
>> and blocking emacs.
>
> I'd argue that it might be a bug.  Why ask for confirmation in this
> case?

Because it is better than nothing (note that it is the intention of the
current code, why it uses confirm-nonexistent-file-or-buffer in first
place and error on second place), of course something like your
proposition of improving find-file-wildcards is better, also it is a
good example showing the need of the feature I propose which could be used
in more places:

    (defun completion--complete-and-exit (beg end
                                              exit-function completion-function)
      "Exit from `require-match' minibuffer.
    COMPLETION-FUNCTION is called if the current buffer's content does not
    appear to be a match."
      (cond
       ;; Allow user to specify null string
       ((= beg end) (funcall exit-function))
       ;; The REQUIRE-MATCH argument is a function.
       ((functionp minibuffer-completion-confirm)
        (pcase (funcall minibuffer-completion-confirm
                        (buffer-substring beg end))
          ((and confirm (or 'confirm 'confirm-after-completion))
           (setq minibuffer-completion-confirm confirm)
           (completion--complete-and-exit
            beg end exit-function completion-function))
          ((pred (eq nil))
           (unless completion-fail-discreetly
    	 (ding)
    	 (completion--message "No match")))
          (_ (funcall exit-function))))
          [...]

>> 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?
>
> Yes, thanks.
>
>> 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.
>
> Agree.
>
>> Thanks for reading and sorry for beeing unclear, it is not easy to
>> explain non trivial things in english.
>
> No need to be sorry, and thanks.
>

-- 
Thierry

Previous Next

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