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 22:30:08 -0500 Message-ID: References: <1227274391.618443.2559.nullmailer@null> <87vduhm69c.fsf@cyd.mit.edu> <87r654yj1f.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 1227324566 5379 80.91.229.12 (22 Nov 2008 03:29:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2008 03:29: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 Sat Nov 22 04:30: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 1L3jCT-0000vQ-AP for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2008 04:30:25 +0100 Original-Received: from localhost ([127.0.0.1]:39544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3jBK-0001q0-48 for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2008 22:29:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3jBF-0001pX-MT for emacs-devel@gnu.org; Fri, 21 Nov 2008 22:29:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3jBE-0001on-81 for emacs-devel@gnu.org; Fri, 21 Nov 2008 22:29:09 -0500 Original-Received: from [199.232.76.173] (port=45288 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3jBE-0001oj-1m for emacs-devel@gnu.org; Fri, 21 Nov 2008 22:29:08 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:25126 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L3jBC-0003rP-Gi; Fri, 21 Nov 2008 22:29:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAMILJ0nO+KUv/2dsb2JhbACBbSvSMYJ8gRs X-IronPort-AV: E=Sophos;i="4.33,648,1220241600"; d="scan'208";a="30171750" Original-Received: from 206-248-165-47.dsl.teksavvy.com (HELO pastel.home) ([206.248.165.47]) by ironport2-out.teksavvy.com with ESMTP; 21 Nov 2008 22:29:05 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E4FF380FF; Fri, 21 Nov 2008 22:30:08 -0500 (EST) In-Reply-To: <87r654yj1f.fsf@cyd.mit.edu> (Chong Yidong's message of "Fri, 21 Nov 2008 14:29:32 -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:105926 Archived-At: >> 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. As explained to Eli, this is not a problem: you usually know that you're creating a new file, so you'll just get used to hitting RET RET blindly in those cases, as a matter of course. >> (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. I can assure you the situation I describe is real, I face it all the time. The situation you describe is when you hit TAB to check your entry before hitting RET. Maybe some people are patient enough to do that. Instead, I hit TAB to complete (not to check) and I hit RET afterwards without even checking the result of TAB because I mistakenly presume Emacs's completion can always read my mind. I know I'm not alone in this. Not that it matters to this discussion anyway. > 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. It's a pretty minor difference. As for [Confirm] being cryptic, we can change it, of course, I don't care about the actual message, I just reused the one used in the other similar case where RET needed to complete the input: nobody complained about that one being cryptic, by the way ;-) Stefan