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 18:40: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><19023.58051.10608.629206@rgr.rgrjr.com> <19025.18385.166444.706321@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 1246844519 15017 80.91.229.12 (6 Jul 2009 01:41:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jul 2009 01:41:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Bob Rogers'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 06 03:41:52 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 1MNdDM-00080x-FS for ged-emacs-devel@m.gmane.org; Mon, 06 Jul 2009 03:41:52 +0200 Original-Received: from localhost ([127.0.0.1]:58430 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNdDL-0006ev-PS for ged-emacs-devel@m.gmane.org; Sun, 05 Jul 2009 21:41:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNdCO-0006Po-Ff for emacs-devel@gnu.org; Sun, 05 Jul 2009 21:40:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNdCJ-0006Ng-TT for emacs-devel@gnu.org; Sun, 05 Jul 2009 21:40:52 -0400 Original-Received: from [199.232.76.173] (port=55564 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNdCJ-0006Na-KZ for emacs-devel@gnu.org; Sun, 05 Jul 2009 21:40:47 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:58910) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MNdCI-0004br-R6 for emacs-devel@gnu.org; Sun, 05 Jul 2009 21:40:47 -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 n661g05C012080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Jul 2009 01:42:02 GMT Original-Received: from abhmt002.oracle.com (abhmt002.oracle.com [141.146.116.11]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n661gQIj009464; Mon, 6 Jul 2009 01:42:26 GMT Original-Received: from dradamslap1 (/24.23.164.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Jul 2009 18:40:40 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <19025.18385.166444.706321@rgr.rgrjr.com> Thread-Index: Acn90kww/ZkaHDXSSSGntgfz9T4mrAABAgUw 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.0A010204.4A515619.00B4: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:112058 Archived-At: > We agree, modulo my wanting to be able to drop modified read-only > buffers without warning. Another way to look at that is that those > buffers typically do not have undo, which is another > indication that we don't expect their contents to be something we > want to worry about saving . . . > > That would be even better, isn't it? Absence of "undo" ought to be a > more reliable indication of which buffers are considered unlikely to > have state the user might regret trashing by accident. Maybe, maybe not. My vague impression is that use of undo can be a bit irregular (odd) sometimes; I'm not sure that presence of undo is the best thing to depend on. > What do you think of querying only for modified buffers with undo enabled? I might be wrong, but I think the `buffer-read-only' test for modified buffers is probably preferable to checking for undo. I think that a read-only modified buffer often represents a different kind of "modification" - one that can generally be ignored here. It's not clear to me how relevant an undo test might be in general - probably sometimes quite relevant, but perhaps sometimes not so relevant. Perhaps someone else can offer insight here. > I notice that this rule would query for Dired buffers, but > only after the user has started marking files. And as soon as > the user types "g", the (buffer-modified-p) flag is cleared again. > This all strikes me as correct behavior. These are all individual preferences, to some extent. One person's significant modifications that s?he wants to be warned about losing is another person's insignificant changes for which a warning would be annoying. Markings and undo in Dired is an example of something I personally don't worry about saving - warning about such changes would represent an annoyance, to me. I'd sooner we concentrate on finding a solution for places where we can identify a real problem - such as you did for `*shell*'. How many modified non-file buffers are in the same class as `*shell*' of holding lots of significant data? Dunno, but we don't want to end up casting a net that is too fine, and thereby catch lots of buffers with modified data that one would never want to save. I wonder if the best approach isn't the suggestion I made to just keep the current test for a warning (i.e., modified file buffers), but add a user option or two to specify buffers or classes of modified buffers (e.g. via regexps) for which warnings would also be issued? The default value of said option(s) could take care of any well-known cases, such as `*shell*'. > In any case, you have convinced me that "C-x k" and "C-x > C-v" should have the same querying behavior. I think you and I are in general agreement now. Whether that has any significance wrt what ultimately gets done about this remains to be seen. Who knows what others might think, and whether even that matters for those who actually decide. All we've heard so far from Stefan is that he wants to add `confirm-nonexistent-file-or-buffer' to the mix (?!). We know that Richard has expressed some interest, and initially a few others offered "fixes" to `find-alternate-file'. But other than that, this seems to be a pas-de-deux. (That in itself is somewhat of an indication, but by no means proof, that this is not a big problem.)