From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: quit-window is broken Date: Tue, 18 Nov 2008 08:33:18 -0800 Message-ID: <001901c9499b$5e8da730$0200a8c0@us.oracle.com> References: <49218C51.4000700@gnu.org> <492195F3.30905@gmx.at><492197C7.6080908@gnu.org> <4921990E.5080106@gmx.at><4921BE23.7010706@gnu.org> <4921C2D3.9090800@gmx.at><4921D754.9040408@gnu.org> <4921F3AA.6000508@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1227026048 5773 80.91.229.12 (18 Nov 2008 16:34:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2008 16:34:08 +0000 (UTC) Cc: 'Emacs Devel' To: "'Stefan Monnier'" , "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 17:35:09 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L2TXb-0001Go-4F for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2008 17:35:03 +0100 Original-Received: from localhost ([127.0.0.1]:51665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2TWS-0002VL-Gp for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2008 11:33:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2TW9-0002Pf-8A for emacs-devel@gnu.org; Tue, 18 Nov 2008 11:33:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2TW8-0002PL-Hs for emacs-devel@gnu.org; Tue, 18 Nov 2008 11:33:32 -0500 Original-Received: from [199.232.76.173] (port=50427 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2TW8-0002PG-Cq for emacs-devel@gnu.org; Tue, 18 Nov 2008 11:33:32 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:30232 helo=rgminet11.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 1L2TW8-00050N-MG for emacs-devel@gnu.org; Tue, 18 Nov 2008 11:33:32 -0500 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAIGXwI8020059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Nov 2008 16:34:00 GMT Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAIGXXV0028230; Tue, 18 Nov 2008 16:33:34 GMT Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Nov 2008 16:33:18 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AclJlwwtD8vcwAPdS4SFlTNHbP0+VQAAEuPw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010202.4922EE50.0051:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:105776 Archived-At: > > C-x C-f is guided by an option - > `find-file-confirm-nonexistent-file'. > > Right. I think this customization variable is an instance of > "Emacs at its worst", so I'd be happy to throw it away. I disagree. Emacs development at its worst would be to change the behavior of basic things such as `C-x C-f' from lax completion to "confirmed" completion without providing users an option to get back the (superior, IMO) original behavior. It's OK to decide, after discussion, that the completion behavior for some new function should be confirmed, not lax or strict. And it's OK to decide, for some existing function, that confirmed should be offered as an alternative to the traditional behavior (whether lax or strict). For a given function, it can happen that there is no need to allow users a choice of completion behaviors - that is probably usually the case. But that is not the case when the behavior is to be changed for a long-existing command, such as `find-file'. In such cases, please keep the traditional behavior as the default behavior, and let users decide. Or change the default if that's better, but give users the choice. > PS: Or we could also add a gzillion foo-confirm-nonexistent-bar > variables for all the places where such a confirmation feature would > come in handy and some user gets annoyed because she > occasionally needs to press RET twice rather than once. Please don't exaggerate. In general, Emacs designers can just pick the most appropriate confirmation behavior for a new function and be done with it - no need to let users choose; no option needed. But that might not apply to a few new functions where there would be some value in giving users a choice (I have none in mind - perhaps there are none). And it generally does not apply to existing functions that affect traditional behavior. Again, "generally" - such cases should be examined case by case.