From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help,gmane.emacs.devel Subject: RE: Q on minibuffer-message Date: Sun, 22 Jan 2006 10:54:35 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137965091 13499 80.91.229.2 (22 Jan 2006 21:24:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2006 21:24:51 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jan 22 22:24:51 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F0mhX-0003Zl-1r for geh-help-gnu-emacs@m.gmane.org; Sun, 22 Jan 2006 22:24:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0mk8-00044D-KO for geh-help-gnu-emacs@m.gmane.org; Sun, 22 Jan 2006 16:27:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F0kP6-0001to-On for help-gnu-emacs@gnu.org; Sun, 22 Jan 2006 13:57:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F0kP3-0001t4-Sb for help-gnu-emacs@gnu.org; Sun, 22 Jan 2006 13:57:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0kP3-0001sg-FG; Sun, 22 Jan 2006 13:57:29 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1F0kTe-0007ut-Tg; Sun, 22 Jan 2006 14:02:15 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k0MIsiaA006902; Sun, 22 Jan 2006 11:54:44 -0700 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0MIsibs006668; Sun, 22 Jan 2006 11:54:44 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-104-212.vpn.oracle.com [141.144.104.212]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0MIshSL006660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 22 Jan 2006 11:54:43 -0700 Original-To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:32778 gmane.emacs.devel:49411 Archived-At: > I have a command `foo' that calls `minibuffer-message' at > various points. > > I want to call this function from another command, `bar', > but I don't want the `minibuffer-message' display to wait > for two seconds - I even don't care > if it is displayed at all in this case. It is not useful to display a minibuffer message and not wait to give the user a chance to see it. The operation must normally wait. Perhaps what you mean is that when foo is used from bar, you see no reason for foo's messages to appear at all. Yes, that's what I mean. In that case, what I suggest is that you set up foo with an optional argument that is provided as t when it is called interactively. And foo should only display its messages when that argument is t. That's just what I wanted to avoid having to do. From my original message: I could change the definition of command `foo', to pass it a flag to not call `minibuffer-message' (or to call it only when the command is called interactively), but I'd rather not have to resort to that. `minibuffer-message' displays its message for two seconds, unless an input event is received during this time. My question is: How can I inhibit the 2-second wait? Is there, for example, some way I can simulate an input event? Or is there a simpler, cleaner way? In command `bar', just after calling `foo', I tried (sit-for 0), to no avail. I tried adding a fake event (e.g. a character) to `unread-command-events', to no avail. I tried binding `minibuffer-message-timeout' (to nil and to 0), to no avail (it seemed to have no effect).