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: minibuffer-message binds inhibit-quit Date: Tue, 24 Jun 2008 15:26:17 -0700 Message-ID: <002e01c8d649$5214f140$0200a8c0@us.oracle.com> References: <001a01c8d63c$273e5f40$0200a8c0@us.oracle.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 1214346494 14150 80.91.229.12 (24 Jun 2008 22:28:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Jun 2008 22:28:14 +0000 (UTC) To: "'Eli Zaretskii'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 00:28:59 2008 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 1KBH0Q-0001uK-NK for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2008 00:28:55 +0200 Original-Received: from localhost ([127.0.0.1]:50554 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KBGza-0002nL-TG for ged-emacs-devel@m.gmane.org; Tue, 24 Jun 2008 18:28:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KBGyi-0002WL-Oo for emacs-devel@gnu.org; Tue, 24 Jun 2008 18:27:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KBGyi-0002Vv-3H for emacs-devel@gnu.org; Tue, 24 Jun 2008 18:27:08 -0400 Original-Received: from [199.232.76.173] (port=53511 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KBGyh-0002VZ-Px for emacs-devel@gnu.org; Tue, 24 Jun 2008 18:27:07 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:32890) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KBGyb-0005if-Ll; Tue, 24 Jun 2008 18:27:02 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m5OMQvDH024091; Tue, 24 Jun 2008 16:26:58 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5O82QS6001026; Tue, 24 Jun 2008 16:26:57 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3698659151214346371; Tue, 24 Jun 2008 15:26:11 -0700 Original-Received: from dradamslap1 (/141.144.81.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Jun 2008 15:26:11 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcjWRNDYk81I0YIaTIedXZEC5isBAAAAE/1g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: 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:99874 Archived-At: > Btw, I think by ``command'' the comment you cited means the command > that called `minibuffer-message'. For example, the message "No match" > is displayed when I type TAB to complete a string that has no > completions; in this case, ``the command'' is the one bound to the TAB > key in the minibuffer, and that command is indeed done when the > message is visible. Perhaps that is the cause of your confusion: you > seem to think that ``the command'' is whatever caused Emacs to enter > the minibuffer in the first place. You're right to distinguish the two sorts of commands. And no doubt the comment refers to a command initiated from the minibuffer during input (e.g. via a minibuffer keymap). But it doesn't follow that that command, which calls `minibuffer-message', is finished as soon as the message is displayed. You can't argue only from a specific example: TAB is done as soon as it displays its message, but `my-cmd', bound to `C-M-S-H-backspace' might not be done as soon as it displays a message. Regardless of which command calls `minibuffer-message', and when, there is no guarantee that the command is "virtually finished" when the message is displayed. A command can do anything after displaying a message. Again, I don't know if the binding is appropriate. This is only about the comment, unless the comment's assumption is a requirement for adding the binding.