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: Sun, 5 Jul 2009 00:10:39 -0700 Message-ID: <4B176CFD1B19450FAE6B14DC326DC48D@us.oracle.com> References: <19020.2798.523236.406366@rgr.rgrjr.com><72597301DECF498C8943373F597732A6@us.oracle.com><19021.23100.86775.844823@rgr.rgrjr.com><19022.27409.779079.636945@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 1246777869 30584 80.91.229.12 (5 Jul 2009 07:11:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jul 2009 07:11:09 +0000 (UTC) Cc: rogers-emacs@rgrjr.dyndns.org, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 05 09:11:02 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 1MNLsM-0000xr-3o for ged-emacs-devel@m.gmane.org; Sun, 05 Jul 2009 09:11:02 +0200 Original-Received: from localhost ([127.0.0.1]:35005 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNLsL-0002un-6A for ged-emacs-devel@m.gmane.org; Sun, 05 Jul 2009 03:11:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNLsF-0002ui-Sp for emacs-devel@gnu.org; Sun, 05 Jul 2009 03:10:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNLsA-0002uP-P3 for emacs-devel@gnu.org; Sun, 05 Jul 2009 03:10:55 -0400 Original-Received: from [199.232.76.173] (port=39004 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNLsA-0002uM-LK for emacs-devel@gnu.org; Sun, 05 Jul 2009 03:10:50 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:46352) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MNLs8-0007F7-5q; Sun, 05 Jul 2009 03:10:48 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MNLs5-0006v2-Cy; Sun, 05 Jul 2009 03:10:45 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n657Btj4009760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Jul 2009 07:11:56 GMT Original-Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n657AhTE022551; Sun, 5 Jul 2009 07:10:44 GMT Original-Received: from dradamslap1 (/24.23.164.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Jul 2009 00:10:35 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acn9BHyqdA2iZj20R4GsfpICUrcj8AAM/JVA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt008.oracle.com [141.146.116.17] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010207.4A5051EC.0068:SCFSTAT5015188,ss=1,fgs=0 X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:112032 Archived-At: > It's best to separate the concerns when analyzing the > problem you ran into: consider both (a) the command > behavior and (b) the key bindings. Whatever the > binding, is `find-alternate-file' dangerous? If so, then > let's fix its behavior. > > It is somewhat dangerous _because_ it has a key binding. No, it was claimed that the command's behavior itself is dangerous, which means regardless of how it is called. The fact that it has a key binding that might cause it to be called unintentionally could be a further risk. It's still best to analyze both issues. > We could try to fix its behavior, but maybe eliminating the > binding is easier. That will not take care of the danger from the command behavior itself, if there is such. AFAICT, the danger (both dangers, in fact), comes from `kill-buffer' not warning and asking for confirmation in the case of a *shell* buffer (or other non-file buffer). If that happened, then there would be no problem whatsoever, IIUC. It warns about modified file buffers, but not modified buffers in general. The OP has, in effect, pointed out that there can be important data in non-file buffers. It is not something special in `find-alternate-file' that is the problem in this regard; it is the fact that it kills the buffer with no warning - and it is just its call of `kill-buffer' that is the culprit there. Removing or changing the `C-x C-v' key binding is, I think, mostly beside the point. If `C-x k' has the same problem, then mistaking a `k' for a `v' presents the same problem as mistaking a `C-v' for a `v' or for a `C-f'. We've heard that the OP has the same problem mistakenly typing either `C-x C-v' or `C-x C-f' instead of `C-x v'. How many other keys are similar enough to a buffer-killing key sequence to present essentially the same problem? If the real problem is the danger of losing data because `kill-buffer' doesn't warn when killing a non-file buffer such as *shell*, then that's what should be addressed. It doesn't make sense to ignore that problem and just start moving keys around, to try to avoid inadvertently killing the buffer in one situation or another. > Fully half the reason I use `find-alternate-file' is to > _kill_ the current buffer (mistaken file visit or not). > I use `C-x C-f' when I want to keep the current buffer, > and `C-x C-v' when I want to kill it. > > Of course, getting rid of the current buffer is why one uses it. So we agree about that. I thought you were suggesting that a history list somehow provided the same utility as `C-x C-v'. > The question is whether it is sufficienty easier than C-x C-k RET and M-p > to justify giving it a key binding. (I think you mean `C-x k', not `C-x C-k'; if not, you've lost me.) FWIW, as far as I'm concerned, the history is pretty irrelevant here. I don't use `C-x C-v' to necessarily (or even usually) change to a file name that is on the history. I use it to visit any file whatsoever (or Dired). (Yes, some of the time I use it because I typed the wrong character and hit RET, but that's not my typical use of it (in spite of the command name). And even in that case, there is nothing particular that the history offers in this regard - nothing implies that the file name I really wanted to type has been accessed previously.) Yes, a user can always use `C-x k' and then `C-x C-f' or whatever. But `C-x k' apparently doesn't warn either. The only safety advantage in doing that instead of `C-x C-v' is if you assume that `C-x k' is less likely to be invoked accidentally. Certainly, there is (at least somewhat) less likelihood of confusion with `C-x v '. But confusion with other keys? The danger of losing "megabytes of data" in *shell* is not logically related to the choice of using a version-control command. _Any_ accidental invocation of _any_ command that kills the *shell* buffer (or another modified buffer) without warning presents the same problem. Confusing `C-x k' with `C-x C-k ' (the kmacro prefix) is every bit as problematic as confusing `C-x C-v' with `C-x v ' (the version-control prefix), I would think. I think the question comes down to whether `kill-buffer' should warn in such a context (modified buffer) or not. If not, then the problem remains, regardless of any key shuffling we might do. If so, then that's the problem to fix.