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: Fri, 3 Jul 2009 15:23:51 -0700 Message-ID: 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 1246659856 4626 80.91.229.12 (3 Jul 2009 22:24:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jul 2009 22:24:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Bob Rogers'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 04 00:24:09 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 1MMrAt-0008QP-0z for ged-emacs-devel@m.gmane.org; Sat, 04 Jul 2009 00:24:07 +0200 Original-Received: from localhost ([127.0.0.1]:60070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMrAr-0005np-TI for ged-emacs-devel@m.gmane.org; Fri, 03 Jul 2009 18:24:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMrAm-0005kG-64 for emacs-devel@gnu.org; Fri, 03 Jul 2009 18:24:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMrAh-0005ZO-Fw for emacs-devel@gnu.org; Fri, 03 Jul 2009 18:23:59 -0400 Original-Received: from [199.232.76.173] (port=39920 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMrAh-0005Z9-Bq for emacs-devel@gnu.org; Fri, 03 Jul 2009 18:23:55 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:22484) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMrAg-0002m0-Nk for emacs-devel@gnu.org; Fri, 03 Jul 2009 18:23:55 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n63MP6bl000534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jul 2009 22:25:08 GMT Original-Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n63MPVL7004484; Fri, 3 Jul 2009 22:25:31 GMT Original-Received: from dradamslap1 (/24.23.164.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Jul 2009 15:23:48 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <19022.27409.779079.636945@rgr.rgrjr.com> Thread-Index: Acn8HY+WzyTG3kwbRjiV9MpD1gfBCgABfWEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt009.oracle.com [141.146.116.18] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4A4E84F5.0196: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:111997 Archived-At: > you may make an advocate of rebinding "C-x C-v" of me yet. ;-} I would sooner see a key-binding change for either `find-alternate-file' or the vc stuff than I would see an unnecessary modification of the command behavior. If key-binding confusion is the problem, then the solution is a key-binding change. If, on the other hand, the command `find-alternate-file' is itself inherently dangerous, then yes, the command behavior should be altered. 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. If not, then if there is a problem caused by key-binding confusion, then change one of the two bindings that people (fingers) confuse. To be clear, I don't have a big problem with changing the binding of `find-alternate-file', assuming the new binding is not something far-fetched. I do think it's important to have a relatively easy-to-use and easily discovered binding for this, because I consider the command useful. Apparently, some users who might be taking advantage of it have never learned that it exists. That's too bad. And I don't agree with Richard that having a history list obviates the usefulness of `find-alternate-file': R> But that is not much of an advantage nowadays, because you can R> get the mistaken file name via the minibuffer history. 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. I wouldn't have thought I was alone in that, but I'm beginning to get the impression that I might be. > > But let me also turn this around: Out of the last X > > times you can remember using C-x C-v, how many of those > > invocations were in a non-file buffer? In other words, > > how likely is it, really, that you might be faced with a > > new prompt, and be forced to deal with it? > > 1. Personally? I use `C-x C-v' _all_ of the time to simultaneously > (a) kill the current buffer - whatever its type (file or non-file) > and (b) visit a file or Dired. All of the time. > > Yes, but I asked for numbers -- even very crude ones -- and > you give me nothing to make me believe that you would actually > be affected by this change more than once in a great while. "_All_ of the time" does not suggest "once in a great while" - at least that was not my intention in using those words. If I had to guess a number, I'd guess between X/3 and X/2. FWIW, that's the same guess I'd make for the buffers I use in general: maybe 2/3 are file buffers. Just a guess. I do not use `C-x C-v' any more or any less depending on the type of buffer to be killed, as I already stated. (Yes, when switching from a file buffer, `find-alternate-file' presents an additional advantage, since the file to be visited is typically in the same directory and sometimes has a similar file name. But that is an advantage relative to other ways to visit a file (e.g. `C-x C-f'); it is not an advantage relative to switching from a non-file buffer.) > how about another alternative: > > 6. Query only if the old current buffer is a modified buffer, > offering to save only for file buffers, and aborting the kill > otherwise. The behavior would change only for > modified non-file buffers (which does include *shell* buffers, > but not most temp buffers), and makes it similar to its > behavior up to 1994. > > How about it? Yes, but I think I would prefer `(or buffer-read-only (buffer-modified-p))'. Killing read-only buffers such as Dired and *Buffer List* that might be modified (e.g. markings) should not bother one by querying. That would likely be my preference, but I can see that it might be debatable. It all depends where one stands on the danger-vs-reminder-annoyance spectrum. I don't have a problem with `find-alternate-file' never querying me more than would `C-x k', but some others might. I have the feeling that the noble motive of protecting from data loss is perhaps being sidetracked here. To me, this is, or should be, about what happens when you ask to kill a given buffer - regardless of how you ask that. Whether you use `C-x k' or `C-x C-v', the buffer to be killed (or the killing operation) should take care of warning you and giving you a change to change your mind, whenever that is appropriate. That is, the _same_ warning/querying behavior is called for, regardless of how you attempt to kill the buffer (interactively). And the behavior that is appropriate depends on the buffer type (and possibly its modified status). The warning/querying behavior should not depend on the particular command that calls for the killing. And it should depend even less on the particular key binding of that command. That is my main point, I guess. I get the feeling that the discussion has been approaching this problem backwards. We should back up from the supposedly problematic key binding `C-x C-v' to the command `find-alternate-file' and finally to the action `kill-buffer'. It's not very important _how_ you ask to kill a buffer. What's important is that you do ask that, and what kind of buffer you are trying to kill. Does `C-x k' warn you the way you would like, when you use it in a *shell* buffer? If not, then that is the problem, not something else. If `C-x k' does warn you adequately, but `C-x C-v' does not, then that is the problem - `find-alternate-file' should act as if `kill-buffer' were called interactively. `find-alternate-file' does run `kill-buffer-query-functions' (but not when it calls `kill-buffer', FWIW). I'm a bit surprised that doesn't take care of the data-loss problem for *shell*. That var is not used in `shell.el'. I would think that the concern for megabytes of data loss would be addressed here, where the data is that could be lost. And as you mentioned, `find-alternate-file' tests `(and (buffer-modified-p) (buffer-file-name))'. I agree with you that the problem you are seeing is coming from `(buffer-file-name)' being nil, and that removing that might be an improvement.