From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: owner@emacsbugs.donarmstrong.com (Emacs bug Tracking System) Newsgroups: gmane.emacs.bugs Subject: bug#2398: marked as done (23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer) Date: Sat, 15 Aug 2009 20:50:05 +0000 Message-ID: References: <87prawn6z8.fsf@cyd.mit.edu> <012c01c992ee$8ec310b0$c2b22382@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1250369405-11564-0" X-Trace: ger.gmane.org 1250370430 7200 80.91.229.12 (15 Aug 2009 21:07:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Aug 2009 21:07:10 +0000 (UTC) To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 15 23:07:03 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1McQSr-0002eU-BJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Aug 2009 23:07:01 +0200 Original-Received: from localhost ([127.0.0.1]:34416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McQSq-0000dp-Oz for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Aug 2009 17:07:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1McQSm-0000dc-Op for bug-gnu-emacs@gnu.org; Sat, 15 Aug 2009 17:06:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1McQSi-0000cp-QE for bug-gnu-emacs@gnu.org; Sat, 15 Aug 2009 17:06:56 -0400 Original-Received: from [199.232.76.173] (port=44045 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McQSi-0000cl-Mj for bug-gnu-emacs@gnu.org; Sat, 15 Aug 2009 17:06:52 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:44904) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1McQSh-0007F1-Vs for bug-gnu-emacs@gnu.org; Sat, 15 Aug 2009 17:06:52 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7FL6n6f015062; Sat, 15 Aug 2009 14:06:50 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n7FKo5Dt011595; Sat, 15 Aug 2009 13:50:05 -0700 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: closed 2398 X-Emacs-PR-Package: emacs X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:30216 Archived-At: This is a multi-part message in MIME format... ------------=_1250369405-11564-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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, con= firm-nonexistent-file-or-buffer has caused the Emacs bug report #2398, regarding 23.0.90; MUSTMATCH read-file-name arg, confirm-nonexistent-file-o= r-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.) --=20 2398: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3D2398 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems ------------=_1250369405-11564-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by emacsbugs.donarmstrong.com; 20 Feb 2009 00:02:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1K02p44018398 for ; Thu, 19 Feb 2009 16:02:52 -0800 Received: from mail.gnu.org ([199.232.76.166]:55564 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LaIoj-0005jB-Mt for emacs-pretest-bug@gnu.org; Thu, 19 Feb 2009 19:00:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LaIqm-0006pC-A1 for emacs-pretest-bug@gnu.org; Thu, 19 Feb 2009 19:02:41 -0500 Received: from rcsinet12.oracle.com ([148.87.113.124]:64466 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LaIql-0006ow-Ev for emacs-pretest-bug@gnu.org; Thu, 19 Feb 2009 19:02:40 -0500 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n1K02X0a012736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 Feb 2009 00:02:35 GMT Received: from acsmt703.oracle.com (acsmt703.oracle.com [141.146.40.81]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n1K02djF003365 for ; Fri, 20 Feb 2009 00:02:40 GMT Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Feb 2009 00:02:31 +0000 From: "Drew Adams" To: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmS7o5OKo5uNZ2mQaO5Ds33anjlMQ== X-Source-IP: acsmt703.oracle.com [141.146.40.81] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.499DF318.0321:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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)' ------------=_1250369405-11564-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 2398-done) by emacsbugs.donarmstrong.com; 15 Aug 2009 20:42:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7FKgPtQ010352 for <2398-done@emacsbugs.donarmstrong.com>; Sat, 15 Aug 2009 13:42:26 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 9E93A57E21C; Sat, 15 Aug 2009 16:43:23 -0400 (EDT) From: Chong Yidong To: "Drew Adams" Cc: <2398-done@emacsbugs.donarmstrong.com> Subject: Re: bug#2398 NOT FIXED - MUSTMATCH read-file-name arg, confirm-nonexistent-file-or-buffer References: <87tz09vtg4.fsf@cyd.mit.edu> <012c01c992ee$8ec310b0$c2b22382@us.oracle.com> <874os8502y.fsf@cyd.mit.edu> Date: Sat, 15 Aug 2009 16:43:23 -0400 In-Reply-To: (Drew Adams's message of "Sat, 15 Aug 2009 13:34:47 -0700") Message-ID: <87prawn6z8.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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. ------------=_1250369405-11564-0--