From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Annoying paren match messages in minibuffer Date: Wed, 14 Jan 2009 21:41:43 -0500 Message-ID: References: <87y6xedc47.fsf@jurta.org> <87ocyat2y5.fsf@cyd.mit.edu> <000401c9765c$e7d22eb0$0200a8c0@us.oracle.com> <87tz818udp.fsf@jurta.org> <002d01c97696$93c6a190$c2b22382@us.oracle.com> <004f01c976ab$8611f9e0$c2b22382@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1231987324 22870 80.91.229.12 (15 Jan 2009 02:42:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2009 02:42:04 +0000 (UTC) Cc: 'Juri Linkov' , 'Chong Yidong' , 'Geoff Gole' , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 15 03:43:15 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 1LNICN-0006As-9J for ged-emacs-devel@m.gmane.org; Thu, 15 Jan 2009 03:43:11 +0100 Original-Received: from localhost ([127.0.0.1]:54852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNIB6-0007H9-NQ for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 21:41:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNIB2-0007Dp-3C for emacs-devel@gnu.org; Wed, 14 Jan 2009 21:41:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNIAz-00079j-Cx for emacs-devel@gnu.org; Wed, 14 Jan 2009 21:41:47 -0500 Original-Received: from [199.232.76.173] (port=43045 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNIAz-00079g-A3 for emacs-devel@gnu.org; Wed, 14 Jan 2009 21:41:45 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:45328 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNIAy-0003yW-Uw for emacs-devel@gnu.org; Wed, 14 Jan 2009 21:41:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAAsxbklMCpxj/2dsb2JhbACBbM0vhW6BbA X-IronPort-AV: E=Sophos;i="4.37,265,1231131600"; d="scan'208";a="32323908" Original-Received: from 76-10-156-99.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.99]) by ironport2-out.teksavvy.com with ESMTP; 14 Jan 2009 21:41:43 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 492867F41; Wed, 14 Jan 2009 21:41:43 -0500 (EST) In-Reply-To: <004f01c976ab$8611f9e0$c2b22382@us.oracle.com> (Drew Adams's message of "Wed, 14 Jan 2009 16:52:20 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:107883 Archived-At: > I gave examples in my reply to Juri. `message' uses the echo area. The > effect is to temporarily replace the minibuffer. And the message can > be preempted if input arrives. Those characteristics can be useful > during some minibuffer dialogs. I don't see any examples here, nor there. In case it's not clear, I expect an example where it would be incorrect/inconvenient for message (inside a minibuffer) to delegate its work to minibuffer-message, and that the incorrectness/inconvenience isn't due (directly or indirectly) to the delay introduced by `message'. >> > You need to be _able_, somehow, to specifically get the normal >> > `minibuffer-message' behavior even when not in the minibuffer (or >> > even when it's not active). >> >> Again, where's the evidence: currently minibuffer-message is >> pretty much unusable in a non-minibuffer buffer, yet I haven't seen >> a single bug report about it. > No one suggested using `minibuffer-message' to display a message outside the > minibuffer. Of course you did: (active-minibuffer-window) can return non-nil outside of the minibuffer, so your suggestion to use choose minibuffer-message based on (active-minibuffer-window) implies to use minibuffer-message (sometimes) outside of a minibuffer. Also the above text says quite explicitly that you sometimes want minibuffer-message's behavior even when not in the minibuffer. > This part of the discussion was about how to know whether/when it > could be appropriate to call `minibuffer-message'. My point here was > that it is not appropriate to do so unless the minibuffer is active, > that is, unless some minibuffer window is active. It is not enough > that a minibuffer window might be the current window. If no user input > is taking place, then `minibuffer-message' is inappropriate. Why not? > Again, see my mail to Juri for descriptions of various cases. It > depends on what you mean by "in a non-minibuffer buffer". Which buffer > is current is not an adequate determination of whether the user is "in > the minibuffer", in the sense of being able to enter input there. If > the minibuffer is active, then the user is generally "in the > minibuffer" in this sense, even if, for the moment, some other buffer > might happen to be current. Open up 2 windows. Run ielm in one of the two. In the other, do M-x, then switch to the ielm window and do (active-minibuffer-window) RET and you'll see that it may return non-nil in cases where the user is not "in the minibuffer", just because it has a minibuffer active somewhere. > temporarily make other buffers current. Throughout this minibuffer dialog, the > minibuffer is _active_, so it generally makes sense to use the > `minibuffer-message' behavior to display messages there. Check the code of minibuffer-message: it displays the message in the current buffer, regardless of whether it's a minibuffer or whether there's an active minibuffer. > `minibufferp' does not do that - it returns non-nil for a minibuffer > even if no minibuffer is active, that is, even if no user input is > possible. Yes. Note that it's pretty much completely irrelevant, because it's pretty damn exceptional for minibufferp to be true while there is no active minibuffer. I.e. what happens in such a corner case is not terribly important. > `active-minibuffer-window' is, IMO, the right test. But you need not > be convinced. Indeed, I'm not. I know there are real cases where it would make the wrong decision, see example below. > What do you mean by an unrelated minibuffer being active? Unrelated to what? Say you have a M-x minibuffer open but you've switched to some other buffer, say a shell buffer and you're using completion and the completion code needs to say "Sole completion": your suggestion would cause a " [Sole completion]" message to be added at the end of the M-x minibuffer (i.e. an unrelated minibuffer), rather than replacing it altogether. Stefan