From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: C-x C-b and C-x C-f bugging about confirmation Date: Fri, 21 Nov 2008 13:03:52 -0500 Message-ID: References: <1227274391.618443.2559.nullmailer@null> <87vduhm69c.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1227290726 12801 80.91.229.12 (21 Nov 2008 18:05:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2008 18:05:26 +0000 (UTC) Cc: ams@gnu.org, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 21 19:06:27 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 1L3aO6-0000J0-Lf for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2008 19:05:51 +0100 Original-Received: from localhost ([127.0.0.1]:39672 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3aMx-0007DV-Sw for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2008 13:04:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3aMJ-0006wg-ER for emacs-devel@gnu.org; Fri, 21 Nov 2008 13:03:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3aMG-0006ud-IC for emacs-devel@gnu.org; Fri, 21 Nov 2008 13:03:58 -0500 Original-Received: from [199.232.76.173] (port=38343 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3aMG-0006uX-D2 for emacs-devel@gnu.org; Fri, 21 Nov 2008 13:03:56 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:43179 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L3aME-0003EA-MW; Fri, 21 Nov 2008 13:03:54 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYFAFeHJklMCrcy/2dsb2JhbACBbSvSPIJ8gRs X-IronPort-AV: E=Sophos;i="4.33,645,1220241600"; d="scan'208";a="30155646" Original-Received: from 76-10-183-50.dsl.teksavvy.com (HELO pastel.home) ([76.10.183.50]) by ironport2-out.teksavvy.com with ESMTP; 21 Nov 2008 13:03:53 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7E65480FF; Fri, 21 Nov 2008 13:03:52 -0500 (EST) In-Reply-To: <87vduhm69c.fsf@cyd.mit.edu> (Chong Yidong's message of "Fri, 21 Nov 2008 10:46:23 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:105897 Archived-At: > have a RET rejected. You might argue that it's no big deal to type a > second RET, but it's similarly no big deal to kill the buffer and try > again in the very few occasions that you make a mistake. So this looks > like creeping featuritis if it's enabled by default. In my experience typos (most commonly after a TAB completion which completed less than expected) are a lot more common than opening a nonexistent file. And hitting RET one more time is much less painful than killing the new buffer and starting over (opening the buffer may have created a frame, may have prompted the user for insertion of a default template, and after killing the buffer you have to repeat the previous command and retype the name all over again). The trade off is blindingly clear to me. My take on it is that if the feature had been the default from the beginning, nobody would even contemplate adding a `confirm-nonexistent-file-or-buffer' option just to save themselves typing RET one extra time when creating a new file. So while I understand that habit will make people complain, I think those complaints will disappear quickly. Stefan