From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: C-x C-b and C-x C-f bugging about confirmation Date: Fri, 21 Nov 2008 14:29:32 -0500 Message-ID: <87r654yj1f.fsf@cyd.mit.edu> 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 1227295782 29781 80.91.229.12 (21 Nov 2008 19:29:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2008 19:29:42 +0000 (UTC) Cc: ams@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 21 20:30:46 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 1L3biE-0008LI-AR for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2008 20:30:42 +0100 Original-Received: from localhost ([127.0.0.1]:41558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3bh5-0004E9-2s for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2008 14:29:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3bgx-0004Ch-Pf for emacs-devel@gnu.org; Fri, 21 Nov 2008 14:29:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3bgs-0004BG-57 for emacs-devel@gnu.org; Fri, 21 Nov 2008 14:29:19 -0500 Original-Received: from [199.232.76.173] (port=60321 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3bgr-0004B9-KO for emacs-devel@gnu.org; Fri, 21 Nov 2008 14:29:17 -0500 Original-Received: from cyd.mit.edu ([18.115.2.24]:53488) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L3bgq-0002b1-KJ; Fri, 21 Nov 2008 14:29:16 -0500 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id 21E1E57E09E; Fri, 21 Nov 2008 14:29:32 -0500 (EST) In-Reply-To: (Stefan Monnier's message of "Fri, 21 Nov 2008 13:03:52 -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:105905 Archived-At: Stefan Monnier writes: > In my experience typos are a lot more common than opening a > nonexistent file. It's a matter of usage patterns. For myself, this change will probably be triggered hundreds or thousands of times for each mistake caught. > (most commonly after a TAB completion which completed less than > expected) Hitting TAB after completion gives the message "[Sole completion]", which tells you that you have what you want. > 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. But it has not been the default from the beginning, and it deviates from established rules about how the minibuffer behaves. One expects RET, unlike TAB, to submit the minibuffer input. (The only time RET doesn't do that is in an "error situation"---a minibuffer is expects an exact match and you haven't supplied that.) Hence this double-RET behavior, with its cryptic "[Confirm]" prompt, is jarring.