From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: undo in loaddefs.el buffer Date: Sun, 26 Dec 2004 23:09:26 -0500 Message-ID: References: <200412211414.iBLEEZ903426@raven.dms.auburn.edu> <200412211541.iBLFfBc03861@raven.dms.auburn.edu> <87llbonyup.fsf@jurta.org> <200412260206.iBQ26wG17970@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1104120985 2435 80.91.229.6 (27 Dec 2004 04:16:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 27 Dec 2004 04:16:25 +0000 (UTC) Cc: juri@jurta.org, yamaoka@jpl.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 27 05:16:19 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 1CimIs-0006tc-00 for ; Mon, 27 Dec 2004 05:16:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CimTf-0004e4-6r for ged-emacs-devel@m.gmane.org; Sun, 26 Dec 2004 23:27:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CimSi-00043r-0q for emacs-devel@gnu.org; Sun, 26 Dec 2004 23:26:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CimSg-00043O-8U for emacs-devel@gnu.org; Sun, 26 Dec 2004 23:26:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CimSg-00042b-54 for emacs-devel@gnu.org; Sun, 26 Dec 2004 23:26:26 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CimHd-0004Q2-Sv for emacs-devel@gnu.org; Sun, 26 Dec 2004 23:15:01 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CimCE-0003Cv-9l; Sun, 26 Dec 2004 23:09:26 -0500 Original-To: Luc Teirlinck In-reply-to: <200412260206.iBQ26wG17970@raven.dms.auburn.edu> (message from Luc Teirlinck on Sat, 25 Dec 2004 20:06:59 -0600 (CST)) 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:31431 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31431 This might be toolkit dependent. (At least for popup menus). If the answer gets asked in the minibuffer, quitting works normally (at least for me). We recently looked at the code in xmenu.c that pops up dialogs, and concluded it could safely run timers. If timers are safe, quitting must be safe. But there could be some case in which it doesn't allow quitting. We should investigate that. Meanwhile, I am not sure it is right for this question to appear as a pop-up menu. yes-or-no-p uses a pop-up menu wen the current command was invoked with the mouse, and that is right when the command itself asks the question, but it may not be right for this. It would be easy to change undo-outer-limit-truncate to use the minibuffer unconditionally.