GNU bug report logs - #2398
23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2398 in the body.
You can then email your comments to 2398 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <emacs-pretest-bug <at> gnu.org>
Subject: 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Thu, 19 Feb 2009 16:02:44 -0800

1. Doc string of `read-file-name' says:
 
 "Fourth arg MUSTMATCH non-nil means require existing file's name.
  Non-nil and non-t means also require confirmation after completion."
 
A value such as `confirm-after-completion' does NOT mean that an
existing file name is required, AFAICT, so the first sentence is
false. Passing a value such as `confirm-after-completion' is no
guarantee that the string returned by `read-file-name' names an
existing file.
 
2. Similarly, the Elisp manual seems incorrect. You are not REQUIRED to
enter the name of an existing file, if MUSTMATCH is, say,
`confirm-after-completion'.  Completion is still lax in this case;
it's just that you must confirm that you want a non-existing file
name.
 
3. Beyond the fact that the doc is inaccurate (and confusing) on this
matter, the new behavior also breaks existing code. Any code that
passed a non-nil non-t value in order to guarantee that the value
returned by the function names an existing file is now broken.
 
4. The user option `confirm-nonexistent-file-or-buffer' is not even
documented in this regard in the Elisp manual.
 
5. The default value of `confirm-nonexistent-file-or-buffer' is
`after-completion', but if you do M-x customize-option
confirm-nonexistent-file-or-buffer you see "Always", not "After
completion", as the current value, and State says STANDARD. Something
is amiss here. Further, you can change the value, using the Value
Menu, to "Always" or to "After completion", but the actual value
remains the same: `after-completion'. This is a mess (bugged), and
quite confusing. And the available values don't seem to
correspond to either the documented completion behavior (see above) or
the actual completion behavior.
 
 
 
In GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600)
 of 2009-02-01 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

Message #10 received at 2398-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 2398-done <at> debbugs.gnu.org
Subject: Re: 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Thu, 19 Mar 2009 00:28:32 -0400

The minibuffer changes have now been documented.

Message #21 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <2398 <at> debbugs.gnu.org>, <emacs-pretest-bug <at> gnu.org>
Subject: RE: bug#2398: 23.0.90;MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Sun, 24 May 2009 16:32:12 -0700

> 2. Similarly, the Elisp manual seems incorrect. You are not 
> REQUIRED to enter the name of an existing file, if MUSTMATCH is, say,
> `confirm-after-completion'.  Completion is still lax in this case;
> it's just that you must confirm that you want a non-existing file
> name.

Not fixed. The manual still says that read-file-name argument REQUIRE-MATCH has
the same meaning as for `completing-read'. And it says nothing about the special
values for this argument and the new behavior they effect.

> 3. Beyond the fact that the doc is inaccurate (and confusing) on this
> matter, the new behavior also breaks existing code. Any code that
> passed a non-nil non-t value in order to guarantee that the value
> returned by the function names an existing file is now broken.

Not fixed.

> 4. The user option `confirm-nonexistent-file-or-buffer' is not even
> documented in this regard in the Elisp manual.

Not fixed.

Message #35 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <2398 <at> debbugs.gnu.org>
Cc: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Subject: RE: bug#2398 NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 12:32:25 -0700

No explanation was given for closing this bug. This is the second time recently
that you've closed a bug I filed without sending any mail explaining the
closure.

The latest info provided in this thread indicates that the bug is still not
fixed. If this bug has been fixed, then what changes were made to fix it? How
can I verify that it has been fixed?

Message #40 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <2398 <at> debbugs.gnu.org>
Subject: Re: bug#2398 NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 15:49:41 -0400

"Drew Adams" <drew.adams <at> oracle.com> writes:

> No explanation was given for closing this bug. This is the second time
> recently that you've closed a bug I filed without sending any mail
> explaining the closure.
>
> The latest info provided in this thread indicates that the bug is
> still not fixed. If this bug has been fixed, then what changes were
> made to fix it? How can I verify that it has been fixed?

It's documented in the Emacs manual and the Lisp manual, as you can
easily check.

Message #45 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: <2398 <at> debbugs.gnu.org>
Subject: RE: bug#2398 NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 13:34:47 -0700

> > No explanation was given for closing this bug. This is the 
> > second time recently that you've closed a bug I filed without
> > sending any mail explaining the closure.
> >
> > The latest info provided in this thread indicates that the bug is
> > still not fixed. If this bug has been fixed, then what changes were
> > made to fix it? How can I verify that it has been fixed?
> 
> It's documented in the Emacs manual and the Lisp manual, as you can
> easily check.

1. Easily?  Well, I either have to build Emacs from CVS or search each of
today's CVS texi files at
http://cvs.savannah.gnu.org/viewvc/emacs/emacs/doc/emacs/ and
http://cvs.savannah.gnu.org/viewvc/emacs/emacs/doc/lispref/. That's hardly
trivial.

You can't be bothered to respond explicitly as to how you fixed the text? Or
point to the relevant passages?

Nevertheless, I did search the CVS texi files until I found relevant passages.
It appears you did correct the text. Thank you for that.

Fixing a bug and closing it entails letting the bug reporter know how it was
fixed. That's been true since the dawn of software. It is irresponsible to just
silently close a bug with no explanation.


2. This bug report was not only about documentation. It also describes a product
regression wrt Emacs 22:

> Any code that passed a non-nil non-t value in order to
> guarantee that the value returned by the function
> names an existing file is now broken.

How will this problem be addressed? Will the regression be fixed? If not, will
the new behavior at least be signaled to users as an incompatible change?

Message #50 received at 2398-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: <2398-done <at> debbugs.gnu.org>
Subject: Re: bug#2398 NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 16:43:23 -0400

>> Any code that passed a non-nil non-t value in order to
>> guarantee that the value returned by the function
>> names an existing file is now broken.
>
> How will this problem be addressed? Will the regression be fixed? If
> not, will the new behavior at least be signaled to users as an
> incompatible change?

No further code changes will be made; and the change is already
documented in NEWS.

Message #55 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>, 2398 <at> debbugs.gnu.org
Cc: cyd <at> stupidchicken.com
Subject: Re: bug#2398: NOT FIXED - MUSTMATCH read-file-name arg,	confirm-nonexistent-file-or-buffer
Date: Sun, 16 Aug 2009 00:10:21 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 15 Aug 2009 13:34:47 -0700
> Cc: 2398 <at> emacsbugs.donarmstrong.com
> 
> > It's documented in the Emacs manual and the Lisp manual, as you can
> > easily check.
> 
> 1. Easily?  Well, I either have to build Emacs from CVS or search each of
> today's CVS texi files at
> http://cvs.savannah.gnu.org/viewvc/emacs/emacs/doc/emacs/ and
> http://cvs.savannah.gnu.org/viewvc/emacs/emacs/doc/lispref/. That's hardly
> trivial.

It is customary to leave the reference to the bug number in the
relevant ChangeLog files.  Using that reference makes it much easier
to find where the bug was fixed.  If such a reference wasn't made in
this case, I think it should.

Message #60 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>, <2398 <at> debbugs.gnu.org>
Cc: <cyd <at> stupidchicken.com>
Subject: RE: bug#2398: NOT FIXED - MUSTMATCH read-file-name arg,	confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 14:15:36 -0700

> > > It's documented in the Emacs manual and the Lisp manual, 
> > > as you can easily check.
> > 
> > 1. Easily?  Well, I either have to build Emacs from CVS or 
> > search each of today's CVS texi files at
> > http://cvs.savannah.gnu.org/viewvc/emacs/emacs/doc/emacs/ and
> > http://cvs.savannah.gnu.org/viewvc/emacs/emacs/doc/lispref/. 
> > That's hardly trivial.
> 
> It is customary to leave the reference to the bug number in the
> relevant ChangeLog files.  Using that reference makes it much easier
> to find where the bug was fixed.  If such a reference wasn't made in
> this case, I think it should.

I didn't realize that. Thanks for the info. Yes, that would help considerably.

FWIW, I don't see `2398' in the Changelog for either manual, but perhaps I
didn't search correctly.

Message #65 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: "'Eli Zaretskii'" <eliz <at> gnu.org>, <2398 <at> debbugs.gnu.org>
Subject: Re: bug#2398: NOT FIXED - MUSTMATCH read-file-name arg,	confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 17:23:45 -0400

"Drew Adams" <drew.adams <at> oracle.com> writes:

> FWIW, I don't see `2398' in the Changelog for either manual, but
> perhaps I didn't search correctly.

I wrote in a reply to bug#2398, on 19 March:

> The minibuffer changes have now been documented.

These are the relevant changelog entries (I didn't put in the bug number
in this case, though I probably should have; the reason is that these
changes were just part of a larger set of revisions to the manual.)

2009-03-15  Chong Yidong  <cyd <at> stupidchicken.com>

   * mini.texi (Completion Commands): Describe Emacs 23 completion rules.
     (Completion Options): Document read-file-name-completion-ignore-case,
     read-buffer-completion-ignore-case, and completion-styles.  Remove
     description of partial-completion-mode.

2009-03-17  Chong Yidong  <cyd <at> stupidchicken.com>

   * minibuf.texi (Basic Completion): Note that
   read-file-name-completion-ignore-case and
   read-buffer-completion-ignore-case can override
   completion-ignore-case.
   (Minibuffer Completion): Document completing-read changes.
   (Completion Commands): Avoid mentioning partial completion mode.
   Document minibuffer-completion-confirm changes, and
   minibuffer-confirm-exit-commands.
   (High-Level Completion): Document new require-match behavior for
   read-buffer.  Document read-buffer-completion-ignore-case.
   (Reading File Names): Document new require-match behavior for
   read-file-name.

Message #70 received at 2398 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: "'Eli Zaretskii'" <eliz <at> gnu.org>, <2398 <at> debbugs.gnu.org>
Subject: RE: bug#2398: NOT FIXED - MUSTMATCH read-file-name arg,	confirm-nonexistent-file-or-buffer
Date: Sat, 15 Aug 2009 14:53:49 -0700

> > FWIW, I don't see `2398' in the Changelog for either manual, but
> > perhaps I didn't search correctly.
> 
> I wrote in a reply to bug#2398, on 19 March:
> 
> > The minibuffer changes have now been documented.

Yes, and I checked the new doc at that time and then replied, saying:

  The manual still says that read-file-name argument
  REQUIRE-MATCH has the same meaning as for `completing-read'.
  And it says nothing about the special values for this argument
  and the new behavior they effect.

Was I mistaken then? It's possible that I was looking at the wrong thing. You
did not reply, however, to let me know, if I was wrong.

> These are the relevant changelog entries (I didn't put in the 
> bug number in this case, though I probably should have...

Yes, it's a little extra work, but it might have saved both of us some effort in
the long run.

At any rate, I probably wouldn't have known to find the references in the
Changelog - now I know better. But I did check the latest CVS doc at the time
and wrote my reply that AFAICT the part I cited was unchanged. (Again, perhaps I
was looking at the wrong thing.)

Previous Next

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