From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: undo in loaddefs.el buffer Date: Mon, 27 Dec 2004 11:21:59 +0100 Message-ID: <41CFE247.8090409@swipnet.se> References: <200412211414.iBLEEZ903426@raven.dms.auburn.edu> <200412211541.iBLFfBc03861@raven.dms.auburn.edu> <87llbonyup.fsf@jurta.org> <200412260206.iBQ26wG17970@raven.dms.auburn.edu> <41CEE3B8.9090600@swipnet.se> <200412270231.iBR2VDE19709@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1104143289 3398 80.91.229.6 (27 Dec 2004 10:28:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Dec 2004 10:28:09 +0000 (UTC) Cc: juri@jurta.org, yamaoka@jpl.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 27 11:28:01 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cis6b-0001SI-00 for ; Mon, 27 Dec 2004 11:28:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CisHN-0002o4-UP for ged-emacs-devel@m.gmane.org; Mon, 27 Dec 2004 05:39:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CisGf-0002nv-BU for emacs-devel@gnu.org; Mon, 27 Dec 2004 05:38:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CisGd-0002nV-Nr for emacs-devel@gnu.org; Mon, 27 Dec 2004 05:38:24 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CisGd-0002nE-5b for emacs-devel@gnu.org; Mon, 27 Dec 2004 05:38:23 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cis1e-0000zm-Tr; Mon, 27 Dec 2004 05:22:55 -0500 Original-Received: from coolsville.localdomain ([83.226.180.210] [83.226.180.210]) by mxfep01.bredband.com with ESMTP id <20041227102253.ILAU18879.mxfep01.bredband.com@coolsville.localdomain>; Mon, 27 Dec 2004 11:22:53 +0100 User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en Original-To: Luc Teirlinck In-Reply-To: <200412270231.iBR2VDE19709@raven.dms.auburn.edu> 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: main.gmane.org gmane.emacs.devel:31451 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31451 Luc Teirlinck wrote: > This way of popping down the dialog has been replaced by popping down by > pressing ESC, which is more in line with what other applications and > toolkits use. > >"Popping down" means returning nil, which for y-or-n-p and yes-or-no-p >means answering "No". Anybody who uses the escape key as a Meta key >can easily answer "No" without wanting to do that. This is especially >bad for yes-or-no-p which, according to the Elisp manual is meant for >"crucial decisions". Intuitively, one would expect "popping down" to >mean quitting, not answering "No". This peculiar behavior is not >documented in the docstrings of y-or-n-p and yes-or-no-p. I could not >find any reference to it in the Elisp manual. > >Apparently, some users expect C-g to _really_ quit from a dialog box, >like it quits in the minibuffer. Instead, it is treated like any >other key. > To have ESC or Ctrl-g (basically any close without using dialog buttons, for example clicking on a window manager close button in the title) do a real quit for a dialog box sounds like a very good idea. I think it is easy to do, because for lucid and lesstif/motif you can already quit dialogs with Ctrl-g (i.e. a real quit), but only if the focus is on the frame, not the dialog. We should make this consistent. For the original case (quitting out of the undo question), that would be an improvement as you could continue to hit Ctrl-g until all questions are gone :-). It is a strange case. I have to hit Ctrl-g three times for the yes-or-no question in the minibuffer to be canceled, but then a yes-or-no dialog pops up. It is the same behaviour regardless of toolkit. Jan D.