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: feature request: indicator of minibuffer-recursion depth Date: Wed, 15 Mar 2006 07:59:38 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1142438439 18987 80.91.229.2 (15 Mar 2006 16:00:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2006 16:00:39 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 15 17:00:37 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FJYQ6-0002bO-Hx for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 17:00:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJYQ5-0000uz-SE for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 11:00:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FJYPh-0000tv-Qv for emacs-devel@gnu.org; Wed, 15 Mar 2006 10:59:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FJYPg-0000sY-21 for emacs-devel@gnu.org; Wed, 15 Mar 2006 10:59:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJYPf-0000sC-AW for emacs-devel@gnu.org; Wed, 15 Mar 2006 10:59:51 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FJYU7-0005Mr-0G for emacs-devel@gnu.org; Wed, 15 Mar 2006 11:04:27 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2FFxnCJ006600 for ; Wed, 15 Mar 2006 09:59:49 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2FFxmEh019725 for ; Wed, 15 Mar 2006 08:59:48 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-72-92.vpn.oracle.com [141.144.72.92]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2FFxlj6019711 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 15 Mar 2006 08:59:48 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:51665 Archived-At: I don't think it's trivial to modify the prompt like that though -- in most cases, the minibuffer prompt is just a part of the minbuffer, and blindly modifying it may screw other things up. Yes. 1) Non-trivial to do well (in all cases). 2) The minibuffer content is often complex already (prompt info, default value info, choice info ([ynq!.]), sometimes minibuffer-message feedback,...) Given that the default is to disable recursive minibuffer use entirely, and the people who intentionally enable such usage tend to be more knowledgeable users (and thus less likely to be confused by recursive minibuffers), it seems that such an indicator would be of somewhat limited applicability. Perhaps, but it wouldn't hurt. Even those intrepid souls who venture within the grotto of recursive minibuffers might appreciate such a compass. Recursive edits are also relatively rare, but we offer a (mode-line) compass for them. FWIW - I have an application that lets users match completion candidates against regexp input. Because it is sometimes simpler to use more than one simple regexp than it is to come up with an equivalent single, complex regexp, they can alternatively enter multiple regexps in recursive minibuffers (to get the match intersection - like grep foo *.c | grep bar | grep toto). This is just an example of using recursive minibuffers with an application. There could be other such uses. (I could of course add a recursion-depth indicator myself, for that particular app.) FWIW2 - In my standalone minibuffer setup I modify the minibuffer-frame background hue slightly each time the minibuffer recursion-depth changes. I also modify it when in isearch. This feedback is subtle, but it helps you "feel" where you are.