From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.help Subject: RE: Q on minibuffer-message Date: Mon, 23 Jan 2006 16:10:49 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1138061898 27923 80.91.229.2 (24 Jan 2006 00:18:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Jan 2006 00:18:18 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 24 01:18:17 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F1Bt2-0007ka-N8 for ged-emacs-devel@m.gmane.org; Tue, 24 Jan 2006 01:18:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F1Bta-00048Y-LT for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 19:18:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F1Boj-0002lu-7i for emacs-devel@gnu.org; Mon, 23 Jan 2006 19:13:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F1Bof-0002l5-1J for emacs-devel@gnu.org; Mon, 23 Jan 2006 19:13:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F1Bod-0002kk-Le; Mon, 23 Jan 2006 19:13:44 -0500 Original-Received: from [148.87.113.118] (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 1F1BtS-0006UH-6i; Mon, 23 Jan 2006 19:18:42 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k0O0Apqc001850; Mon, 23 Jan 2006 17:10:52 -0700 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0O0AprN027325; Mon, 23 Jan 2006 17:10:51 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0O0AoJZ027317 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 23 Jan 2006 17:10:51 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:49472 gmane.emacs.help:32802 Archived-At: > Imagine a scenario where you have no control over the > definition of `foo'. You simply want to use it, but not hear its > `minibuffer-message' noise. Binding `minibuffer-message-timeout' > to 0 (or nil, or t, or whatever) should let you do that. That's all. You have defadvice, which is an official way of committing such crimes of uncleanness. Someone gives you a command that has maybe 10 or 100 possible calls to `minibuffer-message' sprinkled throughout its execution tree. You're going to use `defadvice' to try to slice and dice away the message appearances? Or you're going to rewrite the command, so that it uses a non-interactive helper function or accepts a flag that controls message appearance or tests whether it was called interactively? The original author intended it only as an interactive command, but you see that you can use its functionality as is - you just want to inhibit its messages. In other words, you are asking for a mechanism to subvert the intent of the author of the function which calls `message'. Yes. It's far from atypical to reuse something in a way that was not foreseen by the original author. Probably most reuse fits that description. In any case, `minibuffer-message-timeout' apparently has no effect whatsoever currently: a 2-second delay is apparently hard-coded. When that is fixed, one can hope that a setting of 0 seconds will inhibit display. Some will then use 0 for that purpose; others will prefer more official ways of committing such crimes of uncleanness ;-).