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: Annoying paren match messages in minibuffer Date: Wed, 14 Jan 2009 14:13:24 -0800 Message-ID: <002c01c97695$520f5130$c2b22382@us.oracle.com> References: <87y6xedc47.fsf@jurta.org> <87ocyat2y5.fsf@cyd.mit.edu><000401c9765c$e7d22eb0$0200a8c0@us.oracle.com> <87tz818udp.fsf@jurta.org> 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 1231971432 10190 80.91.229.12 (14 Jan 2009 22:17:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Jan 2009 22:17:12 +0000 (UTC) Cc: 'Chong Yidong' , 'Geoff Gole' , 'Stefan Monnier' , emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 14 23:18:24 2009 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 1LNE46-0005PY-Om for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 23:18:23 +0100 Original-Received: from localhost ([127.0.0.1]:55232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNE2p-0003qK-VU for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 17:17:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNE0x-00029u-7i for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:15:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNE0w-00029B-Bg for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:15:06 -0500 Original-Received: from [199.232.76.173] (port=52482 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNE0w-00028v-34 for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:15:06 -0500 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:42602) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNE0v-0005t1-LV for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:15:05 -0500 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0EMF6vF007228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2009 22:15:07 GMT Original-Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0EMDOWB018749; Wed, 14 Jan 2009 22:13:26 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jan 2009 14:13:23 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tz818udp.fsf@jurta.org> Thread-Index: Acl2janrRzyYdwkMTd+TLJREkLmcIgAAaQig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt701.oracle.com [141.146.40.71] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.496E6385.0179:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:107870 Archived-At: > > I do the same thing myself, but only as a separate function. > > So when I want unconditional behavior (regardless of the > > current buffer) I can still call either `message' or > > `minibuffer-message' instead. > > As a general solution it would be better to change `message' > to take care about the minibuffer's case. It depends what is done to "take care of" things. If it is only automatic and you cannot control it, then no thanks. Something automatic for the general case is fine, as long as you can still specify either behavior (`message' or `minibuffer-message') explicitly in some way. Providing a new, third function for the conditional "smart" behavior is a reasonable approach and will introduce the fewest problems. Modifying `message' to implement that behavior always is not TRT, IMO. > > BTW, don't you need to ensure that the minibuffer window is active? > > I think `active-minibuffer-window' is not suitable for this. > It returns non-nil even when the current buffer is not the minibuffer, That's exactly why `active-minibuffer-window' _is_ suitable for this. The criterion for whether the message should be appended to, rather than replace, the user input is whether the minibuffer is active - not whether it is the current window. Whenever it is active (wherever that active window might be), a user input interaction is going on, and we usually don't want to clobber the user's input. A minibuffer interaction with the user can be under way even if the current buffer changes to another buffer temporarily. I often have another buffer current during periods when the minibuffer is active. A command (e.g. key) executed from the minibuffer can do anything at all, including select various buffers/windows to get something done. Ultimately, of course, focus is usually returned to the minibuffer when such a command completes. But it is not uncommon to want to append a message to the user's input during such an interaction. Nothing says that a minibuffer message (i.e. appended "[...]") is appropriate only when the current buffer is the minibuffer. And nothing says that whenever a minibuffer is the current buffer it is also active (the active minibuffer window). And nothing says that even when it is active you necessarily want the message to take that "[...]" form and have that `minibuffer-message' behavior (e.g. delay). In that context, you might well want to use `message' sometimes, either because you _want_ to temporarily replace the contents with a message (more noticeable) or because you don't want the delay that `minibuffer-message' incurs. `message' is subject to being preempted by input events; `minibuffer-message' is not (IIRC). And `minibuffer-message's delay is unconditional - once it starts, it plays itself out. Each behavior has its advantages, depending on what is wanted. The only generalization here that fits most of the time is that when the minibuffer is _active_ you usually _do_ want that `minibuffer-message' behavior. Usually, but not always. > but there is no need to do this because it doesn't clobber the > current user input (i.e. when the user switched from the active > minibuffer to another buffer). So what? If the minibuffer is not active, then most of the time you do not want the `minibuffer-message' form to be used. And when it is active, it is not necessarily the current buffer. > > FWIW, this is the code I use: > > > > (defun msg-maybe-in-minibuffer (format-string &rest args) > > "Display FORMAT-STRING as a message. > > If called with the minibuffer inactive, use `message'. > > Otherwise, use `minibuffer-message'." > > (if (active-minibuffer-window) > > (save-selected-window > > (select-window (minibuffer-window)) > > (minibuffer-message > > (apply #'format > > (concat " [" format-string "]") args))) > > (apply #'message format-string args))) As I said, even that conditional code (which DTRT more often than code that simply tests whether the minibuffer is the current buffer) is not good enough to be used 100% of the time. I sometimes need to specifically use `message' or `minibuffer-message', to get the behavior I want. Whatever changes you decide to make, please at least be sure to provide some way for programmers to get either behavior explicitly. Don't provide _only_ DWIM code that won't listen to explicit WIM instructions.