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 07:56:10 -0700 Message-ID: <3FE6FCE18E1B42278673EC544B3CE41B@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> <19023.58051.10608.629206@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 1246805799 27274 80.91.229.12 (5 Jul 2009 14:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jul 2009 14:56:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: , "'Bob Rogers'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 05 16:56:32 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 1MNT8p-0001fC-GD for ged-emacs-devel@m.gmane.org; Sun, 05 Jul 2009 16:56:31 +0200 Original-Received: from localhost ([127.0.0.1]:33288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNT8o-0007MI-VF for ged-emacs-devel@m.gmane.org; Sun, 05 Jul 2009 10:56:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNT8i-0007KY-En for emacs-devel@gnu.org; Sun, 05 Jul 2009 10:56:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNT8c-00078v-PT for emacs-devel@gnu.org; Sun, 05 Jul 2009 10:56:23 -0400 Original-Received: from [199.232.76.173] (port=34116 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNT8c-00078X-Cx for emacs-devel@gnu.org; Sun, 05 Jul 2009 10:56:18 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:57033) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MNT8Y-0000Ag-AJ; Sun, 05 Jul 2009 10:56:14 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n65Eu0w7029582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Jul 2009 14:56:01 GMT Original-Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n65EuFQX010324; Sun, 5 Jul 2009 14:56:15 GMT Original-Received: from dradamslap1 (/24.23.164.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Jul 2009 07:56:06 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acn9WfrliaDJ0A6hQjOl3aR49z7h6AAJCK4w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt002.oracle.com [141.146.116.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010201.4A50BF08.001F: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:112041 Archived-At: > But I am really curious to know why Richard changed > this in rev 1.192 to the current (and (buffer-modified-p) > (buffer-file-name)) behavior. Richard, do you remember? > > I don't remember, but I would guess it is becuase most > non-file-visiting buffers don't contain precious information. > I probably did not think about the cases where they do. To be clear about my own position: I said I think the right test for `kill-buffer' to use is `(or buffer-read-only (buffer-modified-p))', but that is only if people decide that loss of data in non-file buffers is indeed a problem that needs solving. Personally, I don't have a problem with the current situation, but if we do decide to make a change to prevent data loss in such buffers, then I think that is the best such change. Another, alternative possibility would be to test whether (besides a modified file buffer) the buffer belongs to some specified set. The set of buffers to warn about could be defined using a list of buffer names or regexps that match buffer names. I mention this because I think it does make sense that most modified non-file buffers _not_ warn you when they are killed - perhaps even most that are not read-only. If `kill-buffer' were to warn each time you kill such a buffer it might prove annoying. However, the `buffer-read-only' test would go a long way toward eliminating such annoyance. Many non-file buffers that would be `buffer-modified-p' are in fact read-only. That includes buffers such as `*grep*', `*Buffer List*', and Dired. The "data" in such buffers is not normally something that we worry about losing accidentally. I guess the question is whether most other non-file buffers are more like `*shell*', where a warning might be appropriate, or are more like `*grep*', where a warning is probably inappropriate. If `*shell*' is rather the exception, then perhaps it would be best to treat it as an exception, using, say, an option `kill-buffer-warn-regexps', with a value of, say, `(,(regexp-quote "*shell*"))'. IOW, do something similar to `same-window-regexps' and `same-window-buffer-names'.