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 18:10:45 -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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1231974673 22106 80.91.229.12 (14 Jan 2009 23:11:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Jan 2009 23:11:13 +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 00:12:25 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 1LNEuE-0001sU-1G for ged-emacs-devel@m.gmane.org; Thu, 15 Jan 2009 00:12:14 +0100 Original-Received: from localhost ([127.0.0.1]:48313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNEsx-0006Sn-Ed for ged-emacs-devel@m.gmane.org; Wed, 14 Jan 2009 18:10:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNEss-0006SA-L8 for emacs-devel@gnu.org; Wed, 14 Jan 2009 18:10:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNEsr-0006R8-5L for emacs-devel@gnu.org; Wed, 14 Jan 2009 18:10:50 -0500 Original-Received: from [199.232.76.173] (port=50908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNEsr-0006R5-27 for emacs-devel@gnu.org; Wed, 14 Jan 2009 18:10:49 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50206) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNEsq-0005nr-PB for emacs-devel@gnu.org; Wed, 14 Jan 2009 18:10:48 -0500 Original-Received: from alfajor.home (vpn-132-204-232-55.acd.umontreal.ca [132.204.232.55]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n0ENBP1i026612; Wed, 14 Jan 2009 18:11:26 -0500 Original-Received: by alfajor.home (Postfix, from userid 20848) id C949B1C15B; Wed, 14 Jan 2009 18:10:45 -0500 (EST) In-Reply-To: <002d01c97696$93c6a190$c2b22382@us.oracle.com> (Drew Adams's message of "Wed, 14 Jan 2009 14:22:24 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3189=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:107875 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. > 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. > 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. > 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. Stefan