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: A wish, a plea Date: Mon, 25 Jun 2007 14:28:16 -0700 Message-ID: References: <87bqf5v5gi.fsf@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: sea.gmane.org 1182806998 4436 80.91.229.12 (25 Jun 2007 21:29:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 21:29:58 +0000 (UTC) To: "Juri Linkov" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 23:29:56 2007 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 1I2w8A-0005qT-E0 for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 23:29:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2w89-00051g-Js for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 17:29:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2w87-00051b-D5 for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:29:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2w84-00051P-TO for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:29:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2w84-00051M-Pj for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:29:48 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I2w84-0004Bk-BI for emacs-devel@gnu.org; Mon, 25 Jun 2007 17:29:48 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5PLTjSL029378; Mon, 25 Jun 2007 16:29:45 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5PLThfN028926; Mon, 25 Jun 2007 15:29:44 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-179.us.oracle.com by acsmt350.oracle.com with ESMTP id 2986620721182806897; Mon, 25 Jun 2007 14:28:17 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87bqf5v5gi.fsf@jurta.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 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:73864 Archived-At: > > ,----[ C-h v confirm-kill-emacs RET ] > > | confirm-kill-emacs is a variable defined in `files.el'. > > | Its value is y-or-n-p > > I customized this option to the same value long ago since this key > combination is easy to mistype. But I guess changing its default value to > always ask confirmation will be undesirable for users who rebound it to > another key which is not easy to mistype. Also this is undesirable when > exiting is invoked from the menu. > > Maybe there should exist a new function (for putting it to > confirm-kill-emacs), and it should check if it was called by > `C-x C-c' and ask confirmation only in this case? Why? I don't get it. Why only for `C-x C-c'? "Will be undesirable for users" who prefer something else is not a problem. That will always be true for some users, no matter what the default behavior is. But they can customize the option. The real question is what the default behavior should be, and who it should target. I argue that possible loss of data is important, and it is especially important for newbies. Those who want to live more dangerously and who don't want to be bothered by the confirmation query can customize this.