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: Fri, 16 Jan 2009 11:10:30 -0800 Message-ID: <006801c9780e$1a0db130$0200a8c0@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><004f01c976ab$8611f9e0$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 1232133248 26549 80.91.229.12 (16 Jan 2009 19:14:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2009 19:14:08 +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 Fri Jan 16 20:15:19 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 1LNu9y-0006Cu-3J for ged-emacs-devel@m.gmane.org; Fri, 16 Jan 2009 20:15:19 +0100 Original-Received: from localhost ([127.0.0.1]:36784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNu8g-0002ZE-Pu for ged-emacs-devel@m.gmane.org; Fri, 16 Jan 2009 14:13:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNu5x-0001qa-8N for emacs-devel@gnu.org; Fri, 16 Jan 2009 14:11:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNu5r-0001oM-5L for emacs-devel@gnu.org; Fri, 16 Jan 2009 14:11:04 -0500 Original-Received: from [199.232.76.173] (port=35819 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNu5q-0001oH-V7 for emacs-devel@gnu.org; Fri, 16 Jan 2009 14:10:59 -0500 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:30082) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNu5p-0008E1-Al for emacs-devel@gnu.org; Fri, 16 Jan 2009 14:10:58 -0500 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0GJCHXk030899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Jan 2009 19:12:18 GMT Original-Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0GJBEVb017570; Fri, 16 Jan 2009 19:11:15 GMT Original-Received: from dradamslap1 (/141.144.80.220) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Jan 2009 19:10:28 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acl2utvGnyWuVbNETuK9nl178jcx2wBP8isA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4970DBAA.0222: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:107912 Archived-At: I really don't have time to discuss this in detail. As long as you keep also the ability to get the traditional `message' (i.e. echo area) behavior somehow, I don't really care how you implement a DWIM feature for messages. However, I strongly advise against simply _replacing_ `message' by any DWIM messaging function - see below for some reasons. A few points in reply, below, in hopes of clearing up some misunderstanding. > > 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, No, the code I sent does `(select-window (minibuffer-window))' if `(active-minibuffer-window)'. The minibuffer message can only appear in the minibuffer, and only when it is active. > so your suggestion to use choose minibuffer-message > based on (active-minibuffer-window) implies to use minibuffer-message > (sometimes) outside of a minibuffer. No, see above. The minibuffer message is always in the minibuffer (with my approach). > > 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. That is precisely a case in which a message from the IELM buffer should use the traditional `message' behavior, that is, use the echo area, not the minibuffer. It is inappropriate for a message to appear in any minibuffer (active or not), if it is unrelated in any way to a minibuffer (i.e. input) operation. And that is an example of why programmers should still be able to specify such non-minibuffer messaging behavior. If some code does not expect to be run during a minibuffer dialog, then it typically does not want to use the minibuffer for its messages. If some code is likely to be used _either_ from the minibuffer or not from it, then it can probably benefit from a DWIM function that DTRT based on the context. IMO, it is not reliable or desirable to substitute a DWIM for `message' in all or even in most cases, regardless of how it is defined. Its use should be reserved for cases where it is likely that the code might be called either from the minibuffer or from top level. For example, some toggle commands make sense when run either at top level or from the minibuffer (via a key) - particularly toggles that affect minibuffer behavior (e.g. input case sensitivity, completion candidate sort order, completion method). A message from such a command, echoing what the new (toggled) value is, can benefit from the automatic determination of which messaging behavior to use. But a message from a command that is very unlikely to be run from the minibuffer should not be subject to such a DWIM guess. There are really two scenarios where the current buffer might not be the active minibuffer, even though the minibuffer is active. One is the scenario you cited. In that case, the user's interaction in IELM is unrelated to the minibuffer that is active somewhere else (for `M-x'). I certainly agree that it makes no sense for IELM to show such a message in the active minibuffer - it makes no sense to show it in _any_ minibuffer. The IELM buffer should use traditional `message' in this context, since it is not currently involved in a minibuffer interaction with the user; the current IELM activity is not part of some overall minibuffer interaction. IELM knows that; a DWIM messaging function cannot know that. The other scenario is where a minibuffer interaction is in progress, and that interaction itself uses other buffers, perhaps making them current at one time or another for various uses, including some user interaction. Overall, the user is involved in a minibuffer dialog - the other buffers are used as part of that minibuffer interaction. Their interaction with the user is generally part of the overall minibuffer interaction. In Icicles, for instance, you can do a lot of things in the context of minibuffer completion: get help on completion candidates, navigate Info, search, perform actions on candidates, etc. Some of those operations can involve making other buffers current at some point. They can involve user interaction with other buffers. Yet, overall, this is all part of a minibuffer dialog. No, this overall interaction is not modal - nothing prevents a user from directly using the other buffers that are part of this interaction, or even other unrelated buffers (such as IELM). But buffers that are part of the overall minibuffer interaction (orchestrated by it, so to speak) should naturally (typically) interact using messages in the (active) minibuffer, since that is the general focus of the user's activity. In this second scenario, it typically makes sense to use the `minibuffer-message' behavior, not to displace the user's input temporarily via the `message' behavior. In my context, that is why I test for `active-minibuffer-window' - to be sure that the minibuffer is active before I use it for a message. Please note the qualifications, such as "typically", above. > 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. Check the code I was talking about (above): it specifically selects the active minibuffer before inserting a message. With my code, `minibuffer-message' is never called with some other buffer current. > > 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. No, it would not, because I would not use the DWIM function (`msg-maybe-in-minibuffer') to display such a message. I would not, because the shell completion code in question is not using the minibuffer, and it is unlikely that it would ever be called from the minibuffer. It should use the normal `message' (echo area) behavior. That particular `Sole completion' message is for non-minibuffer completion - it is totally unrelated to a minibuffer interaction. Summary: 1. `minibuffer-message' behavior is generally appropriate for use by code that is using the minibuffer, whether or not the current buffer at the time of the message is the minibuffer itself. The user's focus here is generally on the minbuffer. (And if the `minibuffer-message' behavior is used here, the (active) minibuffer must first be selected, to display the message there.) 2. `message' behavior is generally appropriate for use by code that is not using the minibuffer, even if the minibuffer might currently be active somewhere for use by some other interaction. 3. It is the function that displays a message that should decide whether it is likely that the message might be shown as part of an overall minibuffer interaction: If the function is likely to be called from the minibuffer, and that message is likely to be part of a minibuffer dialog, then `minibuffer-message' behavior can be appropriate. If the function is likely to be called apart from any minibuffer interaction, then `message' behavior can be appropriate. If both are likely, then `msg-maybe-in-minibuffer' can be appropriate. 4. `message' can sometimes be the right behavior, even when a minibuffer interaction is ongoing, and even when the function displaying the message is generally part of that minibuffer interaction. Some possible reasons: (1) avoid the delay, (2) preempt the message by the arrival of user input, (3) replace the minibuffer content with the echo area temporarily, to temporarily interrupt the dialog and draw attention to the message. 5. Yes, the delay associated with `minibuffer-message' is a problem in general. I don't have an improvement in mind for that. It is one reason that I sometimes use `message' even during minibuffer input (see previous, #1), and I sometimes forego showing a message altogether - if it's not worth a delay, then it's not worth showing (unfortunately). HTH.