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

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

[Drew Adams]

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)'
 

bug#2398: marked as done (23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]


Your message dated Thu, 19 Mar 2009 00:28:32 -0400
with message-id <87mybii1an.fsf@cyd.mit.edu>
and subject line Re: 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
has caused the Emacs bug report #2398,
regarding 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2398: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2398
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4660 bytes --]

From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@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
Message-ID: <012c01c992ee$8ec310b0$c2b22382@us.oracle.com>

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)'
 




[-- Attachment #3: Type: message/rfc822, Size: 1091 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: 2398-done@emacsbugs.donarmstrong.com
Subject: Re: 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
Date: Thu, 19 Mar 2009 00:28:32 -0400
Message-ID: <87mybii1an.fsf@cyd.mit.edu>

The minibuffer changes have now been documented.

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

[Drew Adams]

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

Processed: close 2398

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> close 2398
bug#2398: 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing.
bug closed, send any further explanations to "Drew Adams" <drew.adams@oracle.com>

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Drew Adams]

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?

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Chong Yidong]

"Drew Adams" <drew.adams@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.

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Drew Adams]

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

bug#2398: marked as done (23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]


Your message dated Sat, 15 Aug 2009 16:43:23 -0400
with message-id <87prawn6z8.fsf@cyd.mit.edu>
and subject line Re: bug#2398 NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
has caused the Emacs bug report #2398,
regarding 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2398: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2398
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4660 bytes --]

From: "Drew Adams" <drew.adams@oracle.com>
To: <emacs-pretest-bug@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
Message-ID: <012c01c992ee$8ec310b0$c2b22382@us.oracle.com>

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)'
 




[-- Attachment #3: Type: message/rfc822, Size: 1977 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: <2398-done@emacsbugs.donarmstrong.com>
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
Message-ID: <87prawn6z8.fsf@cyd.mit.edu>

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

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 15 Aug 2009 13:34:47 -0700
> Cc: 2398@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.

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Drew Adams]

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

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Chong Yidong]

"Drew Adams" <drew.adams@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@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@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.

bug#2398: NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer

[Drew Adams]

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