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: Mon, 6 Jul 2009 18:07:19 -0700 Message-ID: <2F7C63D7187F4B44A095A4D99C86AF6F@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> <87vdm5xqpv.fsf@mail.jurta.org> 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 1246928851 13296 80.91.229.12 (7 Jul 2009 01:07:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jul 2009 01:07:31 +0000 (UTC) Cc: rogers-emacs@rgrjr.dyndns.org, emacs-devel@gnu.org To: "'Juri Linkov'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 07 03:07:24 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 1MNz9X-0006GZ-Qs for ged-emacs-devel@m.gmane.org; Tue, 07 Jul 2009 03:07:24 +0200 Original-Received: from localhost ([127.0.0.1]:49752 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNz9X-0000TM-9f for ged-emacs-devel@m.gmane.org; Mon, 06 Jul 2009 21:07:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNz9T-0000SG-7E for emacs-devel@gnu.org; Mon, 06 Jul 2009 21:07:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNz9O-0000Nh-Ry for emacs-devel@gnu.org; Mon, 06 Jul 2009 21:07:18 -0400 Original-Received: from [199.232.76.173] (port=39587 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNz9O-0000NF-IZ for emacs-devel@gnu.org; Mon, 06 Jul 2009 21:07:14 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:36550) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MNz9M-0002w4-LA; Mon, 06 Jul 2009 21:07:12 -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 n6716wm6019300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jul 2009 01:06:59 GMT Original-Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6718qLc015221; Tue, 7 Jul 2009 01:08:53 GMT Original-Received: from dradamslap1 (/141.144.74.13) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 06 Jul 2009 18:07:06 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87vdm5xqpv.fsf@mail.jurta.org> Thread-Index: Acn+nmFzcxUHBM8LSmWO6ZYcb0kSWAAAF10w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010202.4A529FBA.0131: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:112116 Archived-At: > Of course, this raises a question whether an information's > worth in the *shell* buffer is higher than in the *Shell > Command Output* buffer and shouldn't killing the *Shell > Command Output* buffer ask a confirmation as well? > > Then what about the Async shell command that runs a command > in the background? Should C-x C-v ask a confirmation in the > *Async Shell Command* buffer? Currently it simply kills the > child process without a question. > > BTW, I am experiencing a higher risk of losing information with M-! > more than with C-x C-v. M-! is difficult to type with one hand > because the `1' key is located directly above the Shift key, > so a combination with the Meta key often produces the wrong key M-1 > (with Shift unpressed). Typing a shell command in a Dired buffer > without paying attention to the screen results in a complete mess > (since most Dired keybndings are just one letter) that needs to be > analyzed afterwards to determine the damage (looking for files marked, > copied, moved, deleted, etc.) I thought we had moved forward from the question of `find-alternate-file' to the question of `kill-buffer'. If you agree, then please, let's phrase the discussion that way, going forward. The question, for each of the particular contexts you cite, is whether _`kill-buffer'_ should query/warn. How `kill-buffer' might be called is not the point.