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:22:24 -0800 Message-ID: <002d01c97696$93c6a190$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 1231971770 11367 80.91.229.12 (14 Jan 2009 22:22:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Jan 2009 22:22:50 +0000 (UTC) Cc: 'Chong Yidong' , 'Geoff Gole' , emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 14 23:24:01 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 1LNE9U-0007dN-FX for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 23:23:57 +0100 Original-Received: from localhost ([127.0.0.1]:42192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNE8D-0007Wx-PK for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 17:22:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNE89-0007Ws-Sz for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:22:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNE88-0007Wg-GO for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:22:33 -0500 Original-Received: from [199.232.76.173] (port=54396 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNE88-0007Wd-8R for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:22:32 -0500 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:17076) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNE87-0007H5-Sh for emacs-devel@gnu.org; Wed, 14 Jan 2009 17:22:32 -0500 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0EMLsec025649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2009 22:21:56 GMT Original-Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n0EMMO4q008572; Wed, 14 Jan 2009 22:22:25 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Jan 2009 22:22:23 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acl2kxO6TlOk6CnCTsS6SkPUGXTarQAAj9UA 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.0A090205.496E65A1.00FD: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:107873 Archived-At: > > As a general solution it would be better to change `message' > > to take care about the minibuffer's case. > > I see 3 solutions: > 1 - change `message' to use minibuffer-message when in the minibuffer. > As pointed out, the delay can be problematic. 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. > 2 - change minibuffer-message to call `message' when not in > minibuffer. > This is easy to do and shouldn't suffer from those same problems > but won't catch as many cases. Again, the simple test of "in the minibuffer" (or even whether the minibuffer is active, which is more appropriate) is not appropriate for all cases. 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). Currently, a programmer can get any of the behaviors discussed, including the conditional behaviors. Please don't replace that flexibility with a single one-size-fits-all behavior. > 3 - introduce a new function that uses one or the other depending > on `minibufferp'. This won't catch any case until we > start changing code to use it. But it's the safest and easiest > solution. The only hard part would be agreeing on its name. If change there must be, please choose #3. Any name you like. > > I think `active-minibuffer-window' is not suitable for this. > > Indeed, we have `minibufferp' for that. 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. 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.