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?