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: C-x C-v considered harmful Date: Thu, 2 Jul 2009 08:17:59 -0700 Message-ID: <72597301DECF498C8943373F597732A6@us.oracle.com> References: <19020.2798.523236.406366@rgr.rgrjr.com> 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 1246548454 6335 80.91.229.12 (2 Jul 2009 15:27:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2009 15:27:34 +0000 (UTC) To: "'Kevin Rodgers'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 02 17:27:27 2009 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 1MMOC6-0006Ta-UR for ged-emacs-devel@m.gmane.org; Thu, 02 Jul 2009 17:27:27 +0200 Original-Received: from localhost ([127.0.0.1]:52239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMOC6-00052N-0d for ged-emacs-devel@m.gmane.org; Thu, 02 Jul 2009 11:27:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMO30-00071V-CZ for emacs-devel@gnu.org; Thu, 02 Jul 2009 11:18:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMO2u-0006yK-LM for emacs-devel@gnu.org; Thu, 02 Jul 2009 11:18:01 -0400 Original-Received: from [199.232.76.173] (port=34213 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMO2u-0006y8-AB for emacs-devel@gnu.org; Thu, 02 Jul 2009 11:17:56 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:33987) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMO2t-0004lK-Rm for emacs-devel@gnu.org; Thu, 02 Jul 2009 11:17:56 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n62FHj7d003738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jul 2009 15:17:46 GMT Original-Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n62FJVDt013587; Thu, 2 Jul 2009 15:19:31 GMT Original-Received: from dradamslap1 (/141.144.81.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Jul 2009 08:17:50 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acn64T+yNnMKwMycTButKwr76o271gAQ96AQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A4CCF9F.01D5:SCFSTAT5015188,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:111912 Archived-At: Problem statement: >>>> I often invoke vc-dir in the *shell* buffer,... >>>> but sometimes type "C-x C-v d RET" instead... >>>> I haven't let go of the Ctrl key fast enough. Proposed solutions: > >> 1. Bind find-alternate-file to something different. > >> 2. Add a "[Confirm]" step if nonexistent, as for > >> selecting files or buffers with > >> confirm-nonexistent-file-or-buffer set to t. > >> 3. Do not bind find-alternate-file to anything at all. > > > > How about: > > 4. Make find-alternate-file use a yes-or-no-p > > confirmation prompt if the buffer has no associated file. > > My guess is that the vast majority of uses of > > find-alternate-file are replacing one file buffer with > > another, and that intentionally replacing "special" > > buffers is very rare. > > > > If there are specific modes or buffers for which "replacement" > > _is_ commonly used, then there could be a variable to tell > > find-alternate-file not to confirm that buffer (and > > a user could set the global default value of that variable > > to turn off all confirmation) > > The specific mode that leaps to mind is Dired. I often use C-x C-v in > Dired buffers to visit a different directory, just as I do in file > buffers. So how about: > > 5. Make find-alternate-file use a yes-or-no-p confirmation > prompt if the buffer has an associated process. This would > cover *shell* buffers. This is like saying that we should change the behavior of `C-x C-f' so that it asks for confirmation, because if you don't release the Control key fast enough you get `C-x f', which sets the fill column. Or similarly, for `C-x C-b' or `C-x C-c' or `C-x C-d' or ... There are tons of key combinations that exhibit the same "problem". I disagree with all of the above "solutions". The problem is not the behavior of `find-alternate-file' or its binding to `C-x C-v'. If there really is a problem, it is the too-similar binding of `C-x v d'. `C-x C-v' is much older than `C-x v d', and my guess is that it is still more widely used. And `C-x v d' has narrower focus, being specific to the context of change control. If a particular user has a problem finger-confusing `C-x v d' with `C-x C-v', then s?he can use a different key for one or the other. End of problem. If many, many users have the same finger problem, then `C-x v d' should be moved to a different key for everyone. But please don't change the behavior of `find-alternate-file' just because some other key can be confused with `C-x C-v'. Of the "solutions" mentioned above to the "problem", #5 from Kevin R is preferable, being the least restrictive on the behavior of `find-alternate-file'. But there should be no reason to restrict its behavior at all. Fix `C-x v d', if you feel you must, but leave `find-alternate-file' alone. It's been just fine for a third of a century, thank you. It should not be forced to move or change its behavior just because a newcomer to the neighborhood chooses a similar phone #.