From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: feature request: indicator of minibuffer-recursion depth Date: Sat, 16 Jun 2007 02:57:10 +0300 Organization: JURTA Message-ID: <871wgcrctl.fsf@jurta.org> References: <87hcp95lnf.fsf@kfs-lx.testafd.dk> <87sl8t4208.fsf@jurta.org> <87odjgyftq.fsf@jurta.org> <87r6ocss74.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181952031 9775 80.91.229.12 (16 Jun 2007 00:00:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2007 00:00:31 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, storm@cua.dk, miles@gnu.org To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 16 02:00:29 2007 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 1HzLiO-0002Wp-Eo for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2007 02:00:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzLiN-0001WM-UE for ged-emacs-devel@m.gmane.org; Fri, 15 Jun 2007 20:00:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzLiJ-0001W7-I6 for emacs-devel@gnu.org; Fri, 15 Jun 2007 20:00:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzLiF-0001Vl-2o for emacs-devel@gnu.org; Fri, 15 Jun 2007 20:00:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzLiE-0001Vi-QL for emacs-devel@gnu.org; Fri, 15 Jun 2007 20:00:18 -0400 Original-Received: from relay01.kiev.sovam.com ([62.64.120.200]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HzLiC-0007Yd-IV; Fri, 15 Jun 2007 20:00:16 -0400 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1HzLi7-000CKW-LK; Sat, 16 Jun 2007 03:00:14 +0300 In-Reply-To: (Juanma Barranquero's message of "Sat\, 16 Jun 2007 01\:47\:13 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Scanner-Signature: 1e897a521fdb5eac39b1f944f187ca57 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1148 [June 14 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-detected-kernel: FreeBSD 4.8-5.1 (or MacOS X 10.2-10.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:73031 Archived-At: >> It is very easy to add a customizable variable to the Lisp version, >> as you already did in your patch. > > I know. But it is not there, so it's difficult to understand how would > the elisp version (as it stands) be more configurable that the C one. While it is not there, you can redefine `minibuf-depth-setup-minibuffer' in your .emacs. >> Placement can be changed in Lisp by redefining the function >> `minibuf-depth-setup-minibuffer'. And I can do this because I prefer >> putting this indicator to the end of the prompt by using after-string >> instead of before-string. > > That's a bit of a cheat, isn't? For the same reason you can say that > the C version is equally configurable: just don't set > `minibuffer-depth-indicator', and hack something for > `minibuffer-setup-hook'... I like such a configurability of the C version when it means: don't use the C version and start hacking `minibuffer-setup-hook' in Lisp. >> And if it interacts badly with your other eight minibuffer setup hooks, >> you are unable to fix this conflict with the hard-coded C version. > > The C version happens after the hook is run. This is very bad. This means that you have no control on what it does with the minibuffer, and can't fix its bad effects. -- Juri Linkov http://www.jurta.org/emacs/