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 16:52:20 -0800 Message-ID: <004f01c976ab$8611f9e0$c2b22382@us.oracle.com> 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> 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 1231980762 6352 80.91.229.12 (15 Jan 2009 00:52:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2009 00:52:42 +0000 (UTC) Cc: 'Juri Linkov' , 'Chong Yidong' , 'Geoff Gole' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 15 01:53:54 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 1LNGUb-0001kv-LP for ged-emacs-devel@m.gmane.org; Thu, 15 Jan 2009 01:53:54 +0100 Original-Received: from localhost ([127.0.0.1]:59792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNGTL-0005L2-78 for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 19:52:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNGTE-0005Hy-IB for emacs-devel@gnu.org; Wed, 14 Jan 2009 19:52:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNGTD-0005H9-Ra for emacs-devel@gnu.org; Wed, 14 Jan 2009 19:52:28 -0500 Original-Received: from [199.232.76.173] (port=38980 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNGTD-0005Gw-MJ for emacs-devel@gnu.org; Wed, 14 Jan 2009 19:52:27 -0500 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:29020) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNGTD-0002Xd-2r for emacs-devel@gnu.org; Wed, 14 Jan 2009 19:52:27 -0500 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0F0poXO031871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2009 00:51:51 GMT Original-Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0F0qxtT009782; Thu, 15 Jan 2009 00:53:01 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Jan 2009 00:52:18 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acl2nVtFffLatnnTRf62grmIi4Q65gAB8WvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020B.496E88C5.0082: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:107882 Archived-At: > > Not just the delay. You need to be _able_, somehow, to > > specifically get the normal `message' behavior even when > > a minibuffer read is in progress. See my reply to Juri. > > Other than the delay, I see no evidence that what you assert is true. 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. But, as I also said, that is the exception - most of the time, the `minibuffer-message' behavior makes sense during minibuffer input. Believe me (or not); I use both, and I do use such a DWIM most of the time. > > 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. 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. 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. A minibuffer interaction can last, and minibuffer keys can be hit to run commands during that interaction. And some of those commands can do things that 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. The test for being active correctly lets code know whether a session of user input is ongoing, regardless of which window or buffer might be current at the moment. > > See my reply to Juri. `minibufferp' returns non-nil for every > > minibuffer, whether active or not, and it returns non-nil for > > a minibuffer even if _none_ of the minibuffers are active. > > That is, it returns non-nil even if there is no user-input > > interaction going on. That is the wrong condition. > > Care to give a scenario where that's a problem? It's pretty extremely > rare to be inside a minibuffer that's not active, if you ask me. Functions such as `minibuffer-window-active-p' and `active-minibuffer-window' can help distinguish an inactive minibuffer from the active minibuffer (if any). `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. (I do not use `minibufferp' much myself, BTW, because I usually want code that works also with older Emacs versions.) The user is not asked for input except in the _active_ minibuffer. And messages should be written only to the active minibuffer (a la `minibuffer-message') or to the echo area (a la `message'). `active-minibuffer-window' is, IMO, the right test. But you need not be convinced. > > The proper test, IMO, is whether the minibuffer is active, that is, > > whether some minibuffer is active. It has nothing > > (necessarily) to do with the current window/buffer. > > So when some unrelated minibuffer is active, you want to display your > message next to its content, giving the impression that the message > refers to the minibuffer's content? That doesn't sound right at all. What do you mean by an unrelated minibuffer being active? Unrelated to what? AFAIK, at most one minibuffer window can be active at a time. If none is active, then the user is not entering input in a minibuffer. In that case, only the current `message' behavior makes sense, IMO. If a minibuffer window is active, then that is the window where user minibuffer input is to be entered, and it is the window where minibuffer messages ([...]) should be displayed. Perhaps we're not communicating. I don't really care about `active-minibuffer-window' or whether you're convinced wrt my suggestion for coding a DWIM feature for this - do it your way. All I really care about is that programmers will retain the ability to override such a DWIM feature to specifically do what they _really_ mean in some context. IOW, please keep the ability to do either what `message' does today or what `minibuffer-message' does today, whenever the minibuffer is active. If you do that, then there's no harm in adding a DWIM feature such as was proposed, implemented any way you like.