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 15:42:09 -0800 Message-ID: <00a101c97834$0cbe7250$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><006801c9780e$1a0db130$0200a8c0@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 1232149356 12768 80.91.229.12 (16 Jan 2009 23:42:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Jan 2009 23:42:36 +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 Sat Jan 17 00:43:48 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 1LNyLr-0001mE-GP for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2009 00:43:47 +0100 Original-Received: from localhost ([127.0.0.1]:37418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNyKa-0000WF-J8 for ged-emacs-devel@m.gmane.org; Fri, 16 Jan 2009 18:42:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNyKT-0000UY-WF for emacs-devel@gnu.org; Fri, 16 Jan 2009 18:42:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNyKQ-0000RL-L0 for emacs-devel@gnu.org; Fri, 16 Jan 2009 18:42:20 -0500 Original-Received: from [199.232.76.173] (port=58799 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNyKQ-0000R5-EI for emacs-devel@gnu.org; Fri, 16 Jan 2009 18:42:18 -0500 Original-Received: from rcsinet13.oracle.com ([148.87.113.125]:33222 helo=rgminet13.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNyKP-0001bI-HL for emacs-devel@gnu.org; Fri, 16 Jan 2009 18:42:17 -0500 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0GNgu9r010477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Jan 2009 23:42:57 GMT Original-Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0GNg8oe028990; Fri, 16 Jan 2009 23:42:09 GMT Original-Received: from dradamslap1 (/141.144.80.220) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Jan 2009 23:42:06 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acl4HHhUIx0H4lRzT3aZzHanrqqwUQADJ1JA 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.0A090202.49711B51.0011: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:107916 Archived-At: > >> 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. > > Huh? The shell completion is used in M-! I was thinking only of `shell-mode' (you did say "a shell buffer", and you didn't mention minibuffer activation here). Yes, in that case, it would be like the other examples I gave of candidates for such a DWIM. But if the minibuffer is already open elsewhere for `M-x', then how would `M-!' (even somewhere else) act at the same time? It wouldn't. If you meant with non-nil `enable-recursive-minibuffers', then the `M-!' would take over the role of active minibuffer - there is only ever one active minibuffer at a time. The argument remains the same. Only when the minibuffer is active does `minibuffer-message' behavior make sense, and then it makes sense only in the active minibuffer. If you set `enable-recursive-minibuffers' to t, and you have two frames, and you do `M-x' in one frame, and then you do `M-!' in the other frame, the active (recursive) minibuffer follows - it is exactly the right place to display "[Sole completion]" - right where you hit `M-!'. If `enable-recursive-minibuffers' is nil, then you cannot run `M-!' when `M-x' is in progress. If you meant a separate shell buffer, as you said originally, then see my previous response. If the shell completion code doesn't know whether it is run by `M-!' or, say, in `shell-mode', then the DWIM as I defined it is appropriate - the message will show up in the echo area if from a shell buffer, and in the active minibuffer (in the frame where you hit `M-!') otherwise. It will not, as you suggested, show up in the minibuffer that was active (from the `M-x') before you hit `M-!'. > Also I have some work-in-progress patches to replace some of the shell > and lisp-symbol completion code (and sym-comp.el) to use > minibuffer-complete. Yes, I did that myself in fact, in Icicles, and I was going to suggest that you do the same in Emacs, in particular so that users can benefit from the new `completion-styles' feature. (Yes, I am in favor of the feature, even though I think the _default_ completion behavior should not be changed from the traditional behavior.) Good - that will mean I can likely toss my code that enhances each of those separate places because they didn't call `completing-read'. If code that completes buffer text (e.g. symbols, env vars, file names, shell command names) simply calls `completing-read' whenever there are multiple completion candidates, then I can get rid of all of those special-purpose enhancements (hacks). Icicles automatically kicks in (in Icicle mode) whenever `completing-read' is used. > There very much is a need for this completion code > to magically decide when to use message and when to use > minibuffer-message, and until now the best test I've found is > minibufferp, not active-minibuffer-window. Go for it. As I said, I don't care much how you implement it, as long as you leave programmers a way to explicitly get the traditional `message' behavior. And, again, I advise you not to just change `message', which would have a blanket effect even when it's not appropriate, but to instead substitute a new function in those places where it is likely that the code could be called from either a minibuffer or top level.