feature request: indicator of minibuffer-recursion depth

feature request: indicator of minibuffer-recursion depth

[Drew Adams]

For consideration after the release -

Recursive-edit depth is indicated in the mode line by bracketing ([...]).
Being in a recursive minibuffer without knowing it is about as disorienting
as being in a recursive edit without knowing it. AFAIK, there is no feedback
regarding minibuffer-recursion depth.

How about having some indication (somewhere) of the minibuffer-recursion
depth? Perhaps use {...} in the mode line for this (like [...])? (Both
recursions are possible at the same time, though that is not common.)

Re: feature request: indicator of minibuffer-recursion depth

[Masatake YAMATO]

> For consideration after the release -
> 
> Recursive-edit depth is indicated in the mode line by bracketing ([...]).
> Being in a recursive minibuffer without knowing it is about as disorienting
> as being in a recursive edit without knowing it. AFAIK, there is no feedback
> regarding minibuffer-recursion depth.
>
> How about having some indication (somewhere) of the minibuffer-recursion
> depth? 

I think it is good idea.

> Perhaps use {...} in the mode line for this (like [...])? (Both
> recursions are possible at the same time, though that is not common.)

How do you think put [] on the prompt in minibuffer like:

[M-x] 
[[M-x]]
[[[Find file: ]]] ~/

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    > How about having some indication (somewhere) of the
    > minibuffer-recursion depth?

    I think it is good idea.

    > Perhaps use {...} in the mode line for this (like [...])? (Both
    > recursions are possible at the same time, though that is not common.)

    How do you think put [] on the prompt in minibuffer like:
    [M-x]
    [[M-x]]
    [[[Find file: ]]] ~/

We can discuss the design after the release, if people think the idea is
useful.

However, personally I would prefer not to burden the prompt (which can
already be quite complex) and instead put the indicator in the mode line
somehow.

Re: feature request: indicator of minibuffer-recursion depth

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>     > How about having some indication (somewhere) of the
>     > minibuffer-recursion depth?
>
>     I think it is good idea.
>
>     > Perhaps use {...} in the mode line for this (like [...])? (Both
>     > recursions are possible at the same time, though that is not common.)
>
>     How do you think put [] on the prompt in minibuffer like:
>     [M-x]
>     [[M-x]]
>     [[[Find file: ]]] ~/
>
> We can discuss the design after the release, if people think the idea is
> useful.
>
> However, personally I would prefer not to burden the prompt (which can
> already be quite complex) and instead put the indicator in the mode line
> somehow.

The minibuffer does not have a mode line.  And if we want to avoid
confusion, putting the indicator somewhere far away from the
minibuffer would not help.  I think the minibuffer prompt a better
place.  And using the same "recursive" indicator as recursive edits do
in the mode line is sensible as well in my book.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: feature request: indicator of minibuffer-recursion depth

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> The minibuffer does not have a mode line.  And if we want to avoid
> confusion, putting the indicator somewhere far away from the
> minibuffer would not help.  I think the minibuffer prompt a better
> place.  And using the same "recursive" indicator as recursive edits do
> in the mode line is sensible as well in my book.

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.

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.

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: feature request: indicator of minibuffer-recursion depth

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> The minibuffer does not have a mode line.  And if we want to avoid
>> confusion, putting the indicator somewhere far away from the
>> minibuffer would not help.  I think the minibuffer prompt a better
>> place.  And using the same "recursive" indicator as recursive edits do
>> in the mode line is sensible as well in my book.
>
> 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.

Well, there are things like minibuffer-electric-default-mode already
fiddling with the minibuffer prompt, so it would not seem like that
would be inattainable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: feature request: indicator of minibuffer-recursion depth

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Well, there are things like minibuffer-electric-default-mode already
> fiddling with the minibuffer prompt, so it would not seem like that
> would be inattainable.

Certainly not unattainable, but probably rather fiddly.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: feature request: indicator of minibuffer-recursion depth

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 87 bytes --]

I wrote:
> Certainly not unattainable, but probably rather fiddly.

Ok, or maybe not:


[-- Attachment #2: minibuf-depth.el --]
[-- Type: application/emacs-lisp, Size: 2561 bytes --]

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]


-miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

Seems fine (given Richard's decision to put the indicator in the
minibuffer). A minor mode for this is a good idea.

However, the particular indicator you use adds 17 characters to the
minibuffer text, which is often already very busy. Just the number itself
should be sufficient, perhaps followed by a separator such as `)'. IOW,
instead of

 Find file:
 (minibuf-depth 2) Match also (regexp):
 (minibuf-depth 3) Match also (regexp):

use just:

 Find file:
 2) Match also (regexp):
 3) Match also (regexp):

We could add an option whose value is the text to use, with default value
(format "%s)" (minibuffer-depth)).

Re: feature request: indicator of minibuffer-recursion depth

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> However, the particular indicator you use adds 17 characters to the
> minibuffer text, which is often already very busy. Just the number itself
> should be sufficient, perhaps followed by a separator such as `)'. IOW,
> instead of

The reason I chose such a "verbose" indicator is because of David
Reitter's comments:  If the point is to help people avoid confusion (and
such a mode is turned on by default), using a cryptic indicator is
almost as bad as no indicator at all.  I don't think the extra length is
a huge problem, because it will be very rare to actually see this
indicator, and usually the user will simply hit ^G when they do.

On the other hand, if the point is simply to help advanced users
recognize the situation more quickly, then I suppose the format doesn't
matter much.

Clearly it should get the actual indicator format from a variable, as
everybody in this thread seems have their own preferred format.
So the question is more "What should the default format be?", and the
answer depends strongly on what the intention of the indicator really is.

-Miles
-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: feature request: indicator of minibuffer-recursion depth

[Edward O'Connor]

> ;;; minibuf-depth.el --- Indicate minibuffer-depth in prompt

I'm trying this out (with "%d] " as the format string), and it seems
very natural to me.

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: feature request: indicator of minibuffer-recursion depth

[Kim F. Storm]

Miles Bader <miles.bader@necel.com> writes:

> ;;; minibuf-depth.el --- Indicate minibuffer-depth in prompt

Very clever!!  Thanks!

I made a few changes:

1) rename file to mb-depth.el to avoid 8+3 conflict with minibuf-eldef.el
2) use propertized "[%d]" as depth>1 marker
3) added autoload cookie.

I definitely think we should add this little gem.


;;; mb-depth.el --- Indicate minibuffer-depth in prompt
;;
;; Copyright (C) 2006 Free Software Foundation, Inc.
;;
;; Author: Miles Bader <miles@gnu.org>
;; Keywords: convenience

;; This file is part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:
;;
;; Defines the minor mode `minibuffer-indicate-depth-mode'.
;;
;; When active, any recursive use of the minibuffer will show
;; the recursion depth in the minibuffer prompt.  This is only
;; useful if `enable-recursive-minibuffers' is non-nil.

;;; Code:

;; An overlay covering the prompt.  This is a buffer-local variable in
;; each affected minibuffer.
;;
(defvar minibuf-depth-overlay)
(make-variable-buffer-local 'minibuf-depth-overlay)

;; This function goes on minibuffer-setup-hook
(defun minibuf-depth-setup-minibuffer ()
  "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
The prompt should already have been inserted."
  (when (> (minibuffer-depth) 1)
    (setq minibuf-depth-overlay (make-overlay (point-min) (1+ (point-min))))
    (overlay-put minibuf-depth-overlay 'before-string
		 (propertize (format "[%d]" (minibuffer-depth))
			     'face 'highlight))
    (overlay-put minibuf-depth-overlay 'evaporate t)))

;;;###autoload
(define-minor-mode minibuffer-indicate-depth-mode
  "Toggle Minibuffer Indicate Depth mode.
When active, any recursive use of the minibuffer will show
the recursion depth in the minibuffer prompt.  This is only
useful if `enable-recursive-minibuffers' is non-nil.

With prefix argument ARG, turn on if positive, otherwise off.
Returns non-nil if the new state is enabled."
  :global t
  :group 'minibuffer
  (if minibuffer-indicate-depth-mode
      ;; Enable the mode
      (add-hook 'minibuffer-setup-hook 'minibuf-depth-setup-minibuffer)
    ;; Disable the mode
    (remove-hook 'minibuffer-setup-hook 'minibuf-depth-setup-minibuffer)))

(provide 'mb-depth)

;;; mb-depth.el ends here

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    2) use propertized "[%d]" as depth>1 marker

a. I prefer unpropertized (certainly not `highlight'). There is no need to
make this so prominent. It's been missing altogether for decades with no
disastrous consequences.

b. I prefer "%d) ":

 Find file:
 2) Match also (regexp):
 3) Match also (regexp):

instead of "[%d]":

 Find file:
 [2]Match also (regexp):
 [3]Match also (regexp):

There's no need to enclose the level in brackets (or parens or braces).
There is nothing to its left to separate it from. There is a need, howeve,
to separate it from the prompt. At least a space is needed.

Re: feature request: indicator of minibuffer-recursion depth

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

>     2) use propertized "[%d]" as depth>1 marker
>
> a. I prefer unpropertized (certainly not `highlight'). There is no need to
> make this so prominent. It's been missing altogether for decades with no
> disastrous consequences.

But even if you have enabled recursive minibuffers, it happens so rarely
in practice, that I think it makes good sense to bring attention
to the fact that this is indeed a recursive invocation.  Some things
works quite differently when activated in this state.

It sounds like a 

    (defcustom minibuffer-depth-indicator "%d) " 
     ...)

would be the best solution  -- then anyone can change it to their
own liking.their own

>
> b. I prefer "%d) ":
>
>  Find file:
>  2) Match also (regexp):
>  3) Match also (regexp):
>
> instead of "[%d]":
>
>  Find file:
>  [2]Match also (regexp):
>  [3]Match also (regexp):
>

> There's no need to enclose the level in brackets (or parens or braces).

I prefer [n] because it is analogue to the way we indicate recursive edit in the mode line.

> There is nothing to its left to separate it from. There is a need, howeve,
> to separate it from the prompt. At least a space is needed.

Not if you propertize the string, IMHO.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    It sounds like a 
        (defcustom minibuffer-depth-indicator "%d) "  ...)
    would be the best solution  -- then anyone can change it to their
    own liking.

Good idea.

Re: feature request: indicator of minibuffer-recursion depth

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> 1) rename file to mb-depth.el to avoid 8+3 conflict with minibuf-eldef.el

@#$!*& God I hate this stupid kowtowing to a long obsolete brain-damaged
operating system that is only used by about 3 people (none of who've ever
heard of emacs)...!

Anyway, if you're going to do such a thing, please at least limit the
damage as much as you can -- e.g., "mbuf-depth.el" -- it isn't a problem if
the length is greater than 8+3, only if it's ambiguous within that length.

> 2) use propertized "[%d]" as depth>1 marker

It's a good idea to add a face, but the indicator format (and property list
or face?) should clearly be a defcustom because everybody seems to have
their own preferred format...

See my reply to Drew for my thoughts on the default format, especially with
respect to David Reitter's comments.

> 3) added autoload cookie.

Thanks,

-Miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

If this uses a variable to specify the string, it does not need
to be a mode that you can enable or disable.  You could just set
the variable to the empty string.

That makes it so simple that it ought to be installed at the C level
and this avoid needing to use a hook.

Re: feature request: indicator of minibuffer-recursion depth

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> If this uses a variable to specify the string, it does not need
> to be a mode that you can enable or disable.  You could just set
> the variable to the empty string.
>
> That makes it so simple that it ought to be installed at the C level
> and this avoid needing to use a hook.

How about this:


orig = miles@gnu.org--2006/emacs--miles--0--patch-12

M  src/minibuf.c

* modified files

--- orig/src/minibuf.c
+++ mod/src/minibuf.c
@@ -123,6 +123,13 @@
 
 int minibuffer_auto_raise;
 
+/* A string used to indicate minibuffer depths greater than one.
+   It is passed to Fformat, along with the minibuffer depth, and the
+   resulting string added before the minibuffer prompt.  If it is not a
+   string, or its length is zero, then it is ignored.  */
+
+Lisp_Object Vminibuffer_depth_indicator;
+
 /* If last completion attempt reported "Complete but not unique"
    then this is the string completed then; otherwise this is nil.  */
 
@@ -141,6 +148,9 @@
 extern Lisp_Object Qmouse_face;
 
 extern Lisp_Object Qfield;
+
+extern Lisp_Object Qbefore_string;
+
 \f
 /* Put minibuf on currently selected frame's minibuffer.
    We do this whenever the user starts a new minibuffer
@@ -717,6 +727,24 @@
       && !NILP (Vrun_hooks))
     call1 (Vrun_hooks, Qminibuffer_setup_hook);
 
+  if (minibuf_level > 1
+      && STRINGP (Vminibuffer_depth_indicator)
+      && SCHARS (Vminibuffer_depth_indicator) > 0
+      && ZV > BEGV)
+    {
+      Lisp_Object args[4];
+      Lisp_Object ov;
+
+      ov = Fmake_overlay (make_number (BEGV), make_number (BEGV + 1),
+			  Qnil, Qnil, Qnil);
+
+      Foverlay_put (ov, Qevaporate, Qt);
+
+      args[0] = Vminibuffer_depth_indicator;
+      args[1] = make_number (minibuf_level);
+      Foverlay_put (ov, Qbefore_string, Fformat (2, args));
+    }
+
   /* Don't allow the user to undo past this point.  */
   current_buffer->undo_list = Qnil;
 
@@ -2902,6 +2930,13 @@
   Vminibuffer_prompt_properties
     = Fcons (intern ("read-only"), Fcons (Qt, Qnil));
 
+  DEFVAR_LISP ("minibuffer-depth-indicator", &Vminibuffer_depth_indicator,
+	       doc: /* A string used to indicate minibuffer depths greater than one.
+It is passed to `format', along with the minibuffer depth, and the
+resulting string added before the minibuffer prompt.  If it is not a
+string, or its length is zero, then it is ignored.  */);
+    Vminibuffer_depth_indicator = Qnil;
+
   defsubr (&Sset_minibuffer_window);
   defsubr (&Sread_from_minibuffer);
   defsubr (&Seval_minibuffer);





-- 
"1971 pickup truck; will trade for guns"

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

It looks good to me, but it needs to be accompanied by changes in NEWS
and the Emacs Manual and the Lisp Manual.

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 3/20/06, Miles Bader <miles.bader@necel.com> wrote:

> How about this:
>
>
> orig = miles@gnu.org--2006/emacs--miles--0--patch-12
>
> M  src/minibuf.c

The minibuffer-depth-indicator patch was never applied. Perhaps it could be now?

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> The minibuffer-depth-indicator patch was never applied. Perhaps it could be now?

Done.

I've installed a slightly modified version (discussed back then) under the name of
mb-depth.el (to avoid 8.3 conflicts).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

On 6/15/07, Kim F. Storm <storm@cua.dk> wrote:

> Done.
>
> I've installed a slightly modified version (discussed back then) under the name of
> mb-depth.el (to avoid 8.3 conflicts).

I was referring to this C patch by Miles, which Richard said to prefer
(and, honestly, I do too). I see no point in adding an elisp package
(and, worse, stuff to minibuffer-setup-hook) to avoid 15 or 20 lines
of very clean C code.

Could we please try that answer first? (I used it for months with no
problem whatsoever.)

             Juanma


Index: src/minibuf.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/minibuf.c,v
retrieving revision 1.314
diff -u -2 -r1.314 minibuf.c
--- src/minibuf.c	14 Nov 2006 19:25:39 -0000	1.314
+++ src/minibuf.c	15 Nov 2006 08:38:02 -0000
@@ -128,4 +128,11 @@
 int minibuffer_auto_raise;

+/* A string used to indicate minibuffer depths greater than one.
+   It is passed to Fformat, along with the minibuffer depth, and the
+   resulting string added before the minibuffer prompt.	 If it is not a
+   string, or its length is zero, then it is ignored.  */
+
+Lisp_Object Vminibuffer_depth_indicator;
+
 /* If last completion attempt reported "Complete but not unique"
    then this is the string completed then; otherwise this is nil.  */
@@ -151,4 +158,7 @@

 extern Lisp_Object Qfield;
+
+extern Lisp_Object Qbefore_string;
+
 \f
 /* Put minibuf on currently selected frame's minibuffer.
@@ -725,4 +735,22 @@
     call1 (Vrun_hooks, Qminibuffer_setup_hook);

+  if (minibuf_level > 1
+      && STRINGP (Vminibuffer_depth_indicator)
+      && SCHARS (Vminibuffer_depth_indicator) > 0
+      && ZV > BEGV)
+    {
+      Lisp_Object args[4];
+      Lisp_Object ov;
+
+      ov = Fmake_overlay (make_number (BEGV), make_number (BEGV + 1),
+                          Qnil, Qnil, Qnil);
+
+      Foverlay_put (ov, Qevaporate, Qt);
+
+      args[0] = Vminibuffer_depth_indicator;
+      args[1] = make_number (minibuf_level);
+      Foverlay_put (ov, Qbefore_string, Fformat (2, args));
+    }
+
   /* Don't allow the user to undo past this point.  */
   current_buffer->undo_list = Qnil;
@@ -2948,4 +2976,11 @@
   Vread_expression_map = Qnil;

+  DEFVAR_LISP ("minibuffer-depth-indicator", &Vminibuffer_depth_indicator,
+               doc: /* A string used to indicate minibuffer depths
greater than one.
+It is passed to `format', along with the minibuffer depth, and the
+resulting string added before the minibuffer prompt.  If it is not a
+string, or its length is zero, then it is ignored.  */);
+  Vminibuffer_depth_indicator = Qnil;
+
   defsubr (&Sset_minibuffer_window);
   defsubr (&Sread_from_minibuffer);

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: feature request: indicator of minibuffer-recursion depth

[Juri Linkov]

>> I've installed a slightly modified version (discussed back then) under the name of
>> mb-depth.el (to avoid 8.3 conflicts).
>
> I was referring to this C patch by Miles, which Richard said to prefer
> (and, honestly, I do too).

According to the header of this file its author is also Miles.

> I see no point in adding an elisp package (and, worse, stuff to
> minibuffer-setup-hook) to avoid 15 or 20 lines of very clean C code.

There is no reason to add code in C when it is possible to do the same
thing in Emacs Lisp.

Perhaps, creating a new package with just two functions is not justified.
This functionality might fit to one of the existing files.

> Could we please try that answer first? (I used it for months with no
> problem whatsoever.)

The only drawback I see in installed code that it misses the user option
minibuffer-depth-indicator (it was in the C patch).  I suggest adding it
to make this feature more customizable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/15/07, Juri Linkov <juri@jurta.org> wrote:

> There is no reason to add code in C when it is possible to do the same
> thing in Emacs Lisp.

Fragility. My minibuffer-setup-hook already has eight functions.

> The only drawback I see in installed code that it misses the user option
> minibuffer-depth-indicator (it was in the C patch).

Yes, at the very minimum that should be added; the default is useless
to me. But I still think that doesn't belong in an elisp package.

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Stefan Monnier]

>> There is no reason to add code in C when it is possible to do the same
>> thing in Emacs Lisp.
> Fragility.  My minibuffer-setup-hook already has eight functions.

AFAIK, the number of elements on this hook doesn't have any impact
on fragility.

I haven't looked in detail, but unless the Elisp code needs to go through
funny contortions to do its job, it looks like a better option.


        Stefan

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/15/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> AFAIK, the number of elements on this hook doesn't have any impact
> on fragility.

IMO, the more functions in a hook, the bigger the possibility of
unexpected interactions. Call me paranoid.

> I haven't looked in detail, but unless the Elisp code needs to go through
> funny contortions to do its job

No, no funny contortions. It's non configurable, though; it should be fixed.

The C version is not a mode, it's always on (though it does nothing
unless minibuffer-depth-indicator is a string of non-zero length).
That's a big plus in my view. I hate having modes for trivialities: a
new function and a new mode variable just for this. Grr.

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Andreas Röhler]

Am Freitag, 15. Juni 2007 20:39 schrieb Stefan Monnier:
> >> There is no reason to add code in C when it is possible to do the same
> >> thing in Emacs Lisp.
> >
> > Fragility.  My minibuffer-setup-hook already has eight functions.
>
> AFAIK, the number of elements on this hook doesn't have any impact
> on fragility.
>
> I haven't looked in detail, but unless the Elisp code needs to go through
> funny contortions to do its job, it looks like a better option.
>
>
>         Stefan
>
>

Herewith a red-nosed users view in this discussion:

If in a programm it's expected, users will write their
own derived functions from it, I'd prefer elisp, in all
other cases C.

As minibuffer-stuff seems rather an Emacs internal
matter, I'd opt for C.

Thanks to all

Andreas Roehler

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> There is no reason to add code in C when it is possible to do the same
> thing in Emacs Lisp.

I doubt that everyone agrees with that strong statement, but. FWIW, I pretty
much do.

I haven't followed the discussion and the various versions, but I do still
use and appreciate Miles's original Lisp version.

I would also ask that the face used for the overlay be customizable - that
is, use a face variable that defaults to `highlight', or add a new face for
this.

I'm against hard-coding faces, making it impossible for users to configure
things such as this (without changing `highlight' everywhere else as well).

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/15/07, Drew Adams <drew.adams@oracle.com> wrote:

> I would also ask that the face used for the overlay be customizable - that
> is, use a face variable that defaults to `highlight', or add a new face for
> this.

Something like the following patch?

I'd like to make `minibuffer-depth-indicator' a defcustom, but I don't
see a way to allow propertizing it (other than adding a second
variable, ugh).

             Juanma



Index: lisp/mb-depth.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mb-depth.el,v
retrieving revision 1.1
diff -u -2 -r1.1 mb-depth.el
--- lisp/mb-depth.el	15 Jun 2007 14:36:17 -0000	1.1
+++ lisp/mb-depth.el	15 Jun 2007 19:38:36 -0000
@@ -39,4 +39,9 @@
 (make-variable-buffer-local 'minibuf-depth-overlay)

+(defvar minibuffer-depth-indicator (propertize "[%d]" 'face 'highlight)
+  "A string used to indicate minibuffer depths greater than one.
+It is passed to `format', along with the minibuffer depth, and the
+resulting string added before the minibuffer prompt.")
+
 ;; This function goes on minibuffer-setup-hook
 (defun minibuf-depth-setup-minibuffer ()
@@ -46,6 +51,5 @@
     (setq minibuf-depth-overlay (make-overlay (point-min) (1+ (point-min))))
     (overlay-put minibuf-depth-overlay 'before-string
-		 (propertize (format "[%d]" (minibuffer-depth))
-			     'face 'highlight))
+		 (format minibuffer-depth-indicator (minibuffer-depth)))
     (overlay-put minibuf-depth-overlay 'evaporate t)))

@@ -53,7 +57,8 @@
 (define-minor-mode minibuffer-indicate-depth-mode
   "Toggle Minibuffer Indicate Depth mode.
-When active, any recursive use of the minibuffer will show
-the recursion depth in the minibuffer prompt.  This is only
-useful if `enable-recursive-minibuffers' is non-nil.
+When active, any recursive use of the minibuffer will show the
+recursion depth in the minibuffer prompt by means of
+`minibuffer-depth-indicator' (which see).
+This is only useful if `enable-recursive-minibuffers' is non-nil.

 With prefix argument ARG, turn on if positive, otherwise off.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> Something like the following patch?
...
> +(defvar minibuffer-depth-indicator (propertize "[%d]" 'face 'highlight)

Sure, something like that would be OK. 

Better, IMO, would be something that even non-Lispers could use. Just use a face-valued variable in place of the face symbol. Or just add a `defface' and use that new face, not `highlight'.

> I'd like to make `minibuffer-depth-indicator' a defcustom, but I don't
> see a way to allow propertizing it (other than adding a second
> variable, ugh).

What's wrong with that? I do that in Icicles: a variable for the text and a face for the face. 

It beats making users know how to use `propertize' just to customize the appearance of this, IMO. It doesn't take a newbie long to figure out how to change either the face or the text. It would take a newbie long (and s?he'd need a fair amount of confidence) to "customize" a propertized string value such as your indicator's.

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/15/07, Drew Adams <drew.adams@oracle.com> wrote:

> Better, IMO, would be something that even non-Lispers could use. Just use a face-valued variable in place of the face symbol. Or just add a `defface' and use that new face, not `highlight'.

Ugh.

             Juanma

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> > Better, IMO, would be something that even non-Lispers could 
> > use. Just use a face-valued variable in place of the face symbol. 
> > Or just add a `defface' and use that new face, not `highlight'.
> 
> Ugh.

And your reason for your ughness is? Because you enjoy making things harder for users? ;-) Something else?

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/16/07, Drew Adams <drew.adams@oracle.com> wrote:

> And your reason for your ughness is? Because you enjoy making things harder for users? ;-) Something else?

Because this is a tiny feature that I think most users won't
customize, and that doesn't merit (IMHO, etc.) one defcustom, let
alone two...

And more to the point, you're arbitrarily supposing that changing the
text (the "[%s]") and the face is all the user would want to
customize. If you want to be *really* general, allow a function, so I
can do

(setq minibuffer-depth-indicator
      #'(lambda (level)
          (concat (make-string level ?*) " ")))

             Juanma

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> Because this is a tiny feature that I think most users won't
> customize, and that doesn't merit (IMHO, etc.) one defcustom, let
> alone two...

"Most users" misses the mark. It is a self-fulfilling prophecy - if you make it difficult for most users to change this, they won't. Most users will limit their changes to whatever you have facilitated changing. If you require a password that only you know, for instance, then "most users" is limited to (at most) you.

Regardless of the calculation of "most users", you think wrong for at least one user - me. The first thing I did after getting Miles's code was to add a defface and a defcustom to it. Here's my mb-depth+.el, which at least some other users have also been using since last November:

(require 'mb-depth nil t)

(defface mb-depth-indicator '((t (:inherit default)))
  "Face used to indicate minibuffer depth."
  :group 'convenience :group 'faces)

(defcustom mb-depth-indicator-format "%d) "
  "*Format string for minibuffer depth indicator."
  :type 'string :group 'convenience)

;; REPLACE original defined in `mb-depth.el'.
;; Uses customizable format string and face.
(defun minibuf-depth-setup-minibuffer ()
  "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
The prompt should already have been inserted."
  (when (> (minibuffer-depth) 1)
    (setq minibuf-depth-overlay
          (make-overlay (point-min) (1+ (point-min))))
    (overlay-put minibuf-depth-overlay 'before-string
		 (propertize
              (format mb-depth-indicator-format
                     (minibuffer-depth))
              'face 'mb-depth-indicator))
    (overlay-put minibuf-depth-overlay 'evaporate t)))

(provide 'mb-depth+)

Call me silly. Call me interested in "tiny features" that "most users" don't care about. I call someone who thinks that most users don't care about things like this naive - or uninterested in most users. 

Have you seen the use of cell-phone customizing gadgets in, say, Seoul or Bangkok?  Think users don't care much about personalizing the appearance of the things they use? Think again. One might even argue that that's all we _do_ care about. Look at the interest in Emacs color themes or Windows desktop customizing fluff. One fish, two fish, red fish, blue fish.

It's not all silly. But people are passionate even about preferences that others think of as perfectly silly. (Did I mention religious preferences? Oops...)

> And more to the point, you're arbitrarily supposing that changing the
> text (the "[%s]") and the face is all the user would want to
> customize. 

Arbitrarily? No. Judiciously.  Only? No. Typically. Facilitating changing what users typically have preferences about - when you give them the chance. 

I'd be willing to bet that some users will want to change the text, others will want to change the face, and others both. But you won't see any sign of such preferences as long as you make it hard for them to do that.

["Since we've taken a tough stance and stopped listening to them, we haven't heard anything from them." - French government wrt independentists in New Caledonia in the 90s]

> If you want to be *really* general, allow a function, so I can do
> (setq minibuffer-depth-indicator
>       #'(lambda (level)
>           (concat (make-string level ?*) " ")))

That's no more general than doing nothing - you might as well just provide the original source code, to "be *really* general". Arbitrary generality is not the aim, in any case. Ease of use for the target user audience is the aim. This tiny feature is just a user convenience. And, for me, that target audience is not just Lispers.

This is only a "tiny feature", yes, but it is big enough to bring out differences in point of view wrt what you and I think about the appearance and what we think about how much users might care about the appearance. Imagine how much more difference in point of view there must be in the wider user population! This tiny feature is a good litmus test in user friendliness, IMO.

You proposed:
(defvar minibuffer-depth-indicator 
        (propertize "[%d]" 'face 'highlight)

I replied "Sure, something like that would be OK." So I'm not hostile to your effort.

But I pointed out that having a defvar for that is not very useful - it's about the same amount of difficulty (and requires as much Lisp knowledge) to change the appearance using this variable as it would be to change the source code itself - you've simply extracted a piece of code into an internal variable.

Just replacing defvar with defcustom wouldn't help much either, because non-Lispers still wouldn't have a clue how to change the appearance. Just think about how much Lisp you need to know to understand (propertize "[%d]" 'face 'highlight). Seriously - think about it.

And this is something that is _not_ inherently difficult to change. This is a _trivial_ change for users, provided you don't make it unnecessarily hard to change - for most users. Losers indeed.

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/16/07, Drew Adams <drew.adams@oracle.com> wrote:

> "Most users" misses the mark. It is a self-fulfilling prophecy - if you make it difficult for most users to change this, they won't. Most users will limit their changes to whatever you have facilitated changing.

When did Emacs turn into something where every single little
featurette had to be configurable with *customize*? Because I
obviously didn't say that you *shouldn't* be able to change the
minibuffer-depth-indicator. Even in the most customize-friendly
packages, often there are defcustoms and there are defvars (and not
only for internal use).

A few years ago, while discussing the help argument highlighting
support, Richard said:

"To say that a user can customize something does not necessarily mean
introducing a defcustom to customize it.  That is one of many
customization mechanisms in Emacs. Another customization mechanism is
to redefine a function.

Some customizations are natural to do in that way, and some are
important enough to be worth installing a defcustom for.  But we
should refuse to fall into thinking automatically "add a defcustom"
whenever we think something might want to be changed by some users.

Many of those things are definitely not worth adding a defcustom for."

That's exactly what I feel about this feature.

> If you require a password that only you know, for instance,
> then "most users" is limited to (at most) you.

Strawman.

> Regardless of the calculation of "most users", you think wrong
> for at least one user - me.

Only if "most" doesn't mean what I think it means in English...

> The first thing I did after getting Miles's code was to add a
> defface and a defcustom to it.

Judging by the prodigious amount of *+.el packages you produce, I tend
to think this is the first thing you do with everyone's code... (I'm
joking here, please don't take it personally.)

> Call me interested in "tiny features" that "most users" don't care about.

Yes.

> I call someone who thinks that most users don't care about
> things like this naive - or uninterested in most users.

Strawman again. "Things like this" suddenly includes a lot of
customizations that I'm *not* *speaking* *about*. And I didn't propose
making the thing non-customizable; only that the user who wants to do
it takes the effort to use a little lisp. That's what .emacs was for,
I thought.

> Have you seen the use of cell-phone customizing gadgets in, say,
> Seoul or Bangkok?  Think users don't care much about
> personalizing the appearance of the things they use? Think again.

Please, Drew, this is starting to get old. Did I *ever* say that
"users don't care much about personalizing the appearance of the
things they use"? Just *once*? [If you answer this message, don't skip
this question; I'm really interested in the answer.]

> It's not all silly. But people are passionate even about
> preferences that others think of as perfectly silly. (Did I
> mention religious preferences? Oops...)

Don't you thing that's a little over the top? Suddenly I'm
ridiculizing people's religious beliefs?

> Arbitrarily? No. Judiciously.

Ah. So suddenly what you do want to customize is judicious, and what
I'd like is not.

> That's no more general than doing nothing - you might as well just provide the original source code, to "be *really* general". Arbitrary generality is not the aim, in any case. Ease of use for the target user audience is the aim.

And you're the target audience. People who can use customize and
change the color is the target audience. People who knows how to
program, or that is not afraid of adding one line of lisp code to
their .emacs is now not the target audience.

> Imagine how much more difference in point of view there must be in the wider user population! This tiny feature is a good litmus test in user friendliness, IMO.

Please.

> And this is something that is _not_ inherently difficult to change. This is a _trivial_ change for users, provided you don't make it unnecessarily hard to change - for most users. Losers indeed.

Please, don't hesitate to write the defcustom that allows the
customizations you want, and *also* the ones I want (including the
ability to run a function). I swear I won't be opposed to it. You
think it should be customizable, you do the effort.

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Juri Linkov]

> A few years ago, while discussing the help argument highlighting
> support, Richard said:
>
> "To say that a user can customize something does not necessarily mean
> introducing a defcustom to customize it.  That is one of many
> customization mechanisms in Emacs. Another customization mechanism is
> to redefine a function.

I completely agree with Richard.  Actually I argue not against
the C implementation as such, but I argue for customization.
If the C implementation will allow the user to redefine a function,
this would be good for users.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> A few years ago, while discussing the help argument highlighting
> support, Richard said:

> > "To say that a user can customize something does not necessarily mean
> > introducing a defcustom to customize it.  That is one of many
> > customization mechanisms in Emacs. Another customization mechanism is
> > to redefine a function.

I agree with that 100%.  And?

> Some customizations are natural to do in that way, and some are
> important enough to be worth installing a defcustom for.  But we
> should refuse to fall into thinking automatically "add a defcustom"
> whenever we think something might want to be changed by some users.

No one has argued that. Just as no one, including you so far, has argued that we should _never_ add a defcustom when we think users might want to change something, and instead we should _always_ expect them to redefine functions. This is not about "always" and "never". As in all such cases, it's about judgment, not catechism - there is no hardline rule that you can apply in all cases.

People can judge differently. Richard will ultimately judge, and he might well agree with you on this one. I sometimes disagree with Richard and I sometimes agree with him - same as with anyone else. It is not because Richard said what you quoted above that I adhere to it - exegesis doesn't persuade me - I agree with it because I too think that Customize, like anything else, has its limits.

> > The first thing I did after getting Miles's code was to add a
> > defface and a defcustom to it.
> 
> Judging by the prodigious amount of *+.el packages you produce, I tend
> to think this is the first thing you do with everyone's code... (I'm
> joking here, please don't take it personally.)

I don't take it personally; I don't even interpret it as a criticism, personal or technical. Here is the logic behind that practice, in case you are interested:

Miles posted that code as a snippet to emacs-devel. I expected that code to be added to Emacs 22 (with Kim's 8.3 file renaming and possibly with some other changes). That was the gist of the discussion here at that time.

In order that users besides those who read emacs-devel could benefit from it before the release, I posted Miles's snippet to Emacs Wiki (with his name as author) as mb-depth.el - the file name being talked about here at that time. 

Rather than change that code directly, I provided a separate snippet that improves it a bit for at least some users. I posted that snippet to the wiki separately, under my name (only I am to blame for it). There are snippets of enhancements to Emacs code all over the wiki - people use them or don't use them, as they please. Some are posted as separate files for easy loading, some are just pasted on Web pages and people copy them to their .emacs.

I named my snippet file mb-depth+.el for easy reference to the code it enhances. Would you prefer a different file name? Would you prefer that I didn't post the original at all? Would you prefer that I modified the original directly? What would be your preference?

I was unable to supply patches directly at that time (or, rather, FSF was unwilling to accept them, because of a lack of employer papers). I filed bugs. I sometimes filed enhancement requests or suggested enhancements on emacs-devel. I sometimes added enhancements to the wiki as separate *+.el or *-.el files that I wanted to make available to users immediately (vs them waiting until the next release or perhaps forever if the enhancement isn't deemed of general use for Emacs itself).

I act similarly with libraries by others that are not part of Emacs: I write to the authors, proposing my amendment or enhancement, saying that they can add it to their library if they like (and that no attribution to me is needed). If I cannot get a reply or the author doesn't want to add the enhancement to the original library, and if I still think it can be useful, then I add it to the wiki as a separate library, and I use my `+/-' file-name convention to make the connection to the file it enhances. My convention uses `-' for a file to be loaded before, and `+' for a file to be loaded after, the file to be enhanced.

That seems like a good approach, to me. What approach would you prefer that I take, Juanma?

> I didn't propose making the thing non-customizable; only that the
> user who wants to do it takes the effort to use a little lisp.
> That's what .emacs was for, I thought.

Learn Lisp to change a color. Right.

Don't get me wrong - I am all in favor of encouraging Emacs users to learn Lisp. And making them do so to be able to change the text or face used here might help some of them to do that. But others will not learn Lisp for such a minor preference change, and there is no good reason that they should not be able to express their preference also.

> > people are passionate even about preferences that others think
> > of as perfectly silly. (Did I mention religious preferences? Oops...)
> 
> Don't you thing that's a little over the top? Suddenly I'm
> ridiculizing people's religious beliefs?

No, I was hinting that _I_ might be doing so.

The point was that people care about things that might seem to others to be only silly "tiny features". One person's silliness can be another person's sacred object. (In traditional English, the expression would in fact be "sacred cow", but that might offend someone - precisely in keeping with the spirit of this point).

> > That's no more general than doing nothing - you might as well 
> > just provide the original source code, to "be *really* general". 
> > Arbitrary generality is not the aim, in any case. Ease of use for 
> > the target user audience is the aim.
> 
> And you're the target audience. 

?

> People who can use customize and
> change the color is the target audience.

Yes. They are _part_ of the Emacs-user target audience. They too are Emacs users or potential users.

> People who knows how to
> program, or that is not afraid of adding one line of lisp code to
> their .emacs is now not the target audience.

No one said that they are not also part of the target audience. Adding ease of use for non-Lispers does not exclude Lispers. Your approach excludes non-Lisper users. That's OK for some things, but it's not necessary for something as simple as this. Even non-Lispers should be able to customize this tiny feature.

> > And this is something that is _not_ inherently difficult to 
> > change. This is a _trivial_ change for users, provided you don't 
> > make it unnecessarily hard to change - for most users. Losers indeed.
> 
> Please, don't hesitate to write the defcustom that allows the
> customizations you want, and *also* the ones I want (including the
> ability to run a function). I swear I won't be opposed to it. You
> think it should be customizable, you do the effort.

I don't think it's a matter of measuring effort. I am not discounting your effort.

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

    There is no reason to add code in C when it is possible to do the same
    thing in Emacs Lisp.

Oh no!  When something is cleaner in C, we should do it in C.

That is the case here, so would someone please please put in the C
version, and remove the Lisp version?

Re: feature request: indicator of minibuffer-recursion depth

[Juri Linkov]

>     There is no reason to add code in C when it is possible to do the same
>     thing in Emacs Lisp.
>
> Oh no!  When something is cleaner in C, we should do it in C.

What in the C implementation makes it cleaner?

> That is the case here, so would someone please please put in the C
> version, and remove the Lisp version?

I wonder why do you prefer making Emacs less customizable?

In Lisp, the user can change formatting, colors and placement of the
minibuffer depth indicator as the user likes.  But how this can be done
with the C implementation?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/16/07, Juri Linkov <juri@jurta.org> wrote:

> In Lisp, the user can change formatting, colors and placement of the
> minibuffer depth indicator as the user likes. But how this can be done
> with the C implementation?

Have you looked to both implementations as they stand? The only way to
change formatting, colors and placement in the elisp version is by
hacking, while the C version includes a customizable
`minibuffer-depth-indicator' just for that purpose (well, placement
cannot be changed in any of them, truth be told).

It can be added to the elisp version, of course. Or we could just go
with the C version, which would have been committed months ago with no
discussion, were not for the freeze... <sigh>

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Juri Linkov]

>> In Lisp, the user can change formatting, colors and placement of the
>> minibuffer depth indicator as the user likes. But how this can be done
>> with the C implementation?
>
> Have you looked to both implementations as they stand? The only way to
> change formatting, colors and placement in the elisp version is by
> hacking, while the C version includes a customizable
> `minibuffer-depth-indicator' just for that purpose

It is very easy to add a customizable variable to the Lisp version,
as you already did in your patch.

> (well, placement cannot be changed in any of them, truth be told).

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.

> It can be added to the elisp version, of course. Or we could just go
> with the C version, which would have been committed months ago with no
> discussion, were not for the freeze... <sigh>

Please note that the C version uses the same method of putting the overlay
with the formatted indicator to the minibuffer prompt as the Lisp version.
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.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/16/07, Juri Linkov <juri@jurta.org> wrote:

> 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.

> 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'...

> 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.

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Juri Linkov]

>> 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/

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 6/16/07, Juri Linkov <juri@jurta.org> wrote:

> 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 I like what you define as configurability of the elisp version,
which is: "throw the only significant, non-trivial function of the
module and redefine it in your .emacs".

> 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.

Yeah, is quite difficult just to deactivate it.

Whatever.

             Juanma

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

    What in the C implementation makes it cleaner?

It is simple and avoids the need for using hooks.

Please, someone, install the C version
and remove the Lisp version.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

Did this never make it into the release? I don't have a CVS version more
recent than 2006/3/20, but checking the list of source files under CVS now,
I don't see this library. I looked for mb-depth.el, minibuf-depth.el,
mbuf-depth.el, and so on.

This is a useful thing. I think it should not only be present, but should be
enabled by default.

    From: Kim F. Storm [mailto:storm@cua.dk]
    Sent: Thursday, March 16, 2006 1:36 PM
    Subject: Re: feature request: indicator of minibuffer-recursion depth

    Miles Bader <miles.bader@necel.com> writes:
    > ;;; minibuf-depth.el --- Indicate minibuffer-depth in prompt

    Very clever!!  Thanks!
    I made a few changes:

    1) rename file to mb-depth.el to avoid 8+3 conflict with
    minibuf-eldef.el
    ...

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

At this point, I would rather save it for after the release.

Re: feature request: indicator of minibuffer-recursion depth

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> At this point, I would rather save it for after the release.

For those who need this before 23.x, maybe someone would add it to
the EmacsWiki.  Here is the latest version (AFAIK):



;;; mb-depth.el --- Indicate minibuffer-depth in prompt
;;
;; Copyright (C) 2006 Free Software Foundation, Inc.
;;
;; Author: Miles Bader <miles@gnu.org>
;; Keywords: convenience

;; This file is part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:
;;
;; Defines the minor mode `minibuffer-indicate-depth-mode'.
;;
;; When active, any recursive use of the minibuffer will show
;; the recursion depth in the minibuffer prompt.  This is only
;; useful if `enable-recursive-minibuffers' is non-nil.

;;; Code:

;; An overlay covering the prompt.  This is a buffer-local variable in
;; each affected minibuffer.
;;
(defvar minibuf-depth-overlay)
(make-variable-buffer-local 'minibuf-depth-overlay)

;; This function goes on minibuffer-setup-hook
(defun minibuf-depth-setup-minibuffer ()
  "Set up a minibuffer for `minibuffer-indicate-depth-mode'.
The prompt should already have been inserted."
  (when (> (minibuffer-depth) 1)
    (setq minibuf-depth-overlay (make-overlay (point-min) (1+ (point-min))))
    (overlay-put minibuf-depth-overlay 'before-string
		 (propertize (format "[%d]" (minibuffer-depth))
			     'face 'highlight))
    (overlay-put minibuf-depth-overlay 'evaporate t)))

;;;###autoload
(define-minor-mode minibuffer-indicate-depth-mode
  "Toggle Minibuffer Indicate Depth mode.
When active, any recursive use of the minibuffer will show
the recursion depth in the minibuffer prompt.  This is only
useful if `enable-recursive-minibuffers' is non-nil.

With prefix argument ARG, turn on if positive, otherwise off.
Returns non-nil if the new state is enabled."
  :global t
  :group 'minibuffer
  (if minibuffer-indicate-depth-mode
      ;; Enable the mode
      (add-hook 'minibuffer-setup-hook 'minibuf-depth-setup-minibuffer)
    ;; Disable the mode
    (remove-hook 'minibuffer-setup-hook 'minibuf-depth-setup-minibuffer)))

(provide 'mb-depth)

;;; mb-depth.el ends here

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: feature request: indicator of minibuffer-recursion depth

[Mathias Dahl]

> For those who need this before 23.x, maybe someone would add it to
> the EmacsWiki.  Here is the latest version (AFAIK):

Done:

http://www.emacswiki.org/cgi-bin/wiki/mb-depth.el

/Mathias

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> From: Kim F. Storm Sent: Monday, July 17, 2006 1:33 AM
> For those who need this before 23.x, maybe someone would add it to
> the EmacsWiki.  Here is the latest version (AFAIK):
>
> ;;; mb-depth.el --- Indicate minibuffer-depth in prompt
> ...

Mathias uploaded this to the Wiki last July.

When this is eventually added to a release, I would like to see these two
things be user-configurable, not hard-coded:

- the depth-indicator format (currently hard-coded "[%d]")
- the depth-indicator face (currently hard-coded `highlight')

For my own use, I've defined a face and a format-string user option for
this. I use "%d) ", instead of "[%d]", for the default value of the format,
and I use `default' for the default value of the face (inheritance).

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 11/19/06, Drew Adams <drew.adams@oracle.com> wrote:

> > ;;; mb-depth.el --- Indicate minibuffer-depth in prompt

I like better Miles patch for src/minibuf.c. It's about 22 lines (not
counting comments or blank lines). I've been using it in my working
Emacs for months.

                    /L/e/k/t/u

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> > > ;;; mb-depth.el --- Indicate minibuffer-depth in prompt
> 
> I like better Miles patch for src/minibuf.c. It's about 22 lines (not
> counting comments or blank lines). I've been using it in my working
> Emacs for months.

I'm not aware of it. Can you describe it - does it do what mb-depth does? Can users control the appearance?

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 11/19/06, Drew Adams <drew.adams@oracle.com> wrote:

> I'm not aware of it.

http://lists.gnu.org/archive/html/emacs-devel/2006-03/msg00840.html

                    /L/e/k/t/u

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> On 11/19/06, Drew Adams <drew.adams@oracle.com> wrote:
> > I'm not aware of it.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2006-03/msg00840.html
 
Thanks. So I guess Kim was mistaken when he wrote on 7/17 that it wouldn't be in Emacs 22? And Richard misunderstood when he said on 7/17 that he wanted to save it for after the release?

Very good, in any case. And I'm glad to see that the format string is a user variable (`minibuffer-depth-indicator'). I don't see a user-definable face, but perhaps no face is used. That would be fine with me; I use `default' anyway, just to get rid of the hard-coded `highlight' in mb-depth.el.

BTW, when did this make it into Emacs? I have a July 19 build, in which it is still absent, though the message you cite is from March.

Re: feature request: indicator of minibuffer-recursion depth

[Juanma Barranquero]

On 11/19/06, Drew Adams <drew.adams@oracle.com> wrote:

> Thanks. So I guess Kim was mistaken when he wrote on 7/17 that it wouldn't be in Emacs 22? And Richard misunderstood when he said on 7/17 that he wanted to save it for after the release?

No. As far as I know, it has not been committed.

I pointed it out because it is quite small and seems better than
having an elisp package just for this.

> Very good, in any case. And I'm glad to see that the format string is a user variable (`minibuffer-depth-indicator'). I don't see a user-definable face, but perhaps no face is used.

You can always do, as I do:

 (defface my-minibuffer-depth-face ...)

 (setq minibuffer-depth-indicator
       (propertize "[%d] " 'face 'my-minibuffer-depth-face)))

                    /L/e/k/t/u

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> No. As far as I know, it has not been committed.

OK, so I guess we're back to hoping for it to be added to a later release.

Until that happens, I've uploaded a trivial mb-depth.el tweak to Emacs Wiki (mb-depth+.el) that lets you define the format and face. It won't be useful or needed, once the C code is committed.

> I pointed it out because it is quite small and seems better than
> having an elisp package just for this.

Yes. Looking forward to it.

> Very good, in any case. And I'm glad to see that the format 
> string is a user variable (`minibuffer-depth-indicator'). I don't 
> see a user-definable face, but perhaps no face is used.
> 
> You can always do, as I do:
>  (defface my-minibuffer-depth-face ...)
>  (setq minibuffer-depth-indicator
>        (propertize "[%d] " 'face 'my-minibuffer-depth-face)))

Yes, good. And it's good that no highlighting is hard-coded in the C version, so one is not obliged to add a face definition just to get rid of the highlighting.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

        From: Kim F. Storm [mailto:storm@cua.dk]
        Miles Bader <miles.bader@necel.com> writes:
        > ;;; minibuf-depth.el --- Indicate minibuffer-depth in prompt
        Very clever!!  Thanks! I made a few changes:
        1) rename file to mb-depth.el to avoid 8+3 conflict with
        minibuf-eldef.el ...

    From:Drew Adams
    Did this never make it into the release? ...
    This is a useful thing. I think it should not only be present,
    but should be enabled by default.

  From: Richard Stallman Sent: Sunday, July 16, 2006 6:42 PM
  At this point, I would rather save it for after the release.

Why? This wouldn't impact anything else in any way, especially if it were
turned off by default. The code itself is miniscule. I think this is quite
useful.

It could even be argued that having *no* user feedback to indicate that you
are in a recursive minibuffer is a *bug* - even a serious UI bug. It is
this, more than anything else, that turns a recursive minibuffer into a mine
field: users don't know what's happening. With this feedback, the mine field
is cleared, IMO.

That was why I brought this up in the first place: I argued that [[...]] in
the mode line was a good indication of recursive editing, and something
similar is missing for recursive minibuffers. I originally suggested
indicating this too in the mode line, but I'm happy with the solution
implemented by Miles.

Imagine if we had no [...] in the mode line for recursive edits. Wouldn't
you consider that a bug? Wouldn't a recursive edit become a mine field too,
without feedback?

Re: feature request: indicator of minibuffer-recursion depth

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

[...]

> 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.

Uh, what?  We are not talking about

[You are in recursive minibuffer mode! Press C-g to exit it]

We are talking about

[[M-x]] ...

You already need to have a clue about the concept to interpret that.

Anyway, don't be too sure that everybody with disabled recursive
minibuffer has intentionally done so: most people's dotemacs is pasted
together from multiple sources without a clue.

One should probably place an electronic signature into dotemacs files
and prohibit people from using any code they have not entered all by
themselves.

But I guess this scheme would not be compatible with GPL3.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

    One should probably place an electronic signature into dotemacs files
    and prohibit people from using any code they have not entered all by
    themselves.

    But I guess this scheme would not be compatible with GPL3.

GPLv3 would have nothing to say about the matter as long as users
really can change the code and get rid of the feature.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    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.

Re: feature request: indicator of minibuffer-recursion depth

[Stefan Monnier]

> 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,...)

I don't think it has to be hard.  The least-intrusive way is probably to not
add text in the (mini)buffer, but to use overlays with after/before-strings.


        Stefan

Re: feature request: indicator of minibuffer-recursion depth

[David Reitter]

On 15 Mar 2006, at 09:28, Miles Bader wrote:

> 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.

Let's say it adds another visual clue that wants to be deciphered.  
The cost/benefit ratio is debatable.

Either way, since you are implying that the default setting  
(recursive minibuffers off) is easier to understand, I'd like to  
bring up the following problem that the default behavior may pose.
Let's step through a simple thought experiment, logging the steps a  
user would sometimes experience:

- User wants to switch to a file.
- User types C-x C-f by mistake.
- User realizes: oh, the file is already loaded, I'd actually like to  
switch to a buffer.
- User types C-x b to switch to the buffer.
- Error appears :"Command attempted to use minibuffer while in  
minibuffer"
    (point of frustration, because command doesn't work.)
- (*) user has to a) understand the error message,
- (*) and type C-g to  quit the first prompt.
- and then repeat C-x b.

Now, the steps marked (*) require the user to be knowledgeable. I  
remember well that C-g was one of the essential commands that I  
didn't learn early on, so the situation caused a lot of frustration.  
And because issuing the wrong command happens often when you're new  
to Emacs, you get frustrated rather often. [Part of the trouble is  
that it's C-g and not Esc, but that can't be changed.]

So if you're seriously considering modifying the minibuffer  
interaction before the release, I urge you to make the default  
setting (no recursion) easier to use. One solution would be to  
automatically quit the command that's occupying the minibuffer  
whenever another command requires it (i.e. instead of signaling the  
above error). I proposed something like that a while ago, and the  
reason that I haven't implemented it is that I have no clue how to  
properly do a non-local exit.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    I remember well that C-g was one of the essential commands that I
    didn't learn early on, so the situation caused a lot of frustration.

Not that this is a defense of `C-g' or anything else, but one thing I
learned many moon ago is that perhaps the first thing to learn about
something new is how to stop it, get out of it, quit it, or (if possible)
undo it. ;-) `C-x C-c' and `C-g' should be emblazoned on the startup screen.

[This goes for teaching, as well, BTW. And the second thing to teach is how
to use or modify something (e.g. a program) that exists, not how to create a
new one; it's nearly always simpler (and more rewarding to newbies, and more
informative) to use or change something that exists than it is to create one
from scratch.]

    So if you're seriously considering modifying the minibuffer
    interaction before the release,

I was clear in my initial proposal to consider this feature - here is the
first line of that message (emphasis added):

 For consideration ***after*** the release -

    I urge you to make the default setting (no recursion) easier to use.

The message could be improved. When I see "Command attempted to use
minibuffer while in minibuffer" my reaction is "Of course the command I'm
using in the minibuffer attempts to use the minibuffer while in the
minibuffer!"

There are two problems understanding the message: 1) "Command" - what
command? I might not be aware that I invoked a command. 2) "use the
minibuffer" is not clear.

This might be better: "`...' (command `...') cannot be run during minibuffer
input", where the first `...' is whatever you typed that invoked a command,
and the second `...' is the command name. For your example, the message
would be:

 `C-x b' (command `switch-to-buffer') cannot be run during minibuffer input

Additional info *might* be added to the message, and the command name might
be dropped. Some additional info that could help:

. Mention that the command cannot be run because it would, itself, ask for
input

. Mention that you can toggle `enable-recursive-minibuffers' to allow the
command to be run.

Another possibility for the message:

 You cannot use `C-x b' while entering input, because it too prompts for
input

    One solution would be to
    automatically quit the command that's occupying the minibuffer
    whenever another command requires it (i.e. instead of signaling the
    above error).

That might be confusing also. If you don't realize that what you type is
bound to a command, then you think you are still inputting what the first
command wants, and in fact the first command has already been (silently)
offed.

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

Regarding the proposal for recursive minibuffer commands to
quit the outer minibuffer:

Can someone please investigate what UI experts suggest about this
kind of case?

Re: feature request: indicator of minibuffer-recursion depth

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Regarding the proposal for recursive minibuffer commands to
> quit the outer minibuffer:

Uh, don't they do that already by default?

> Can someone please investigate what UI experts suggest about this
> kind of case?

I am afraid we already lost them with "minibuffer", never mind about
"recursive".  vi has something like that, but you can't leave the
minibuffer leaving pending stuff behind, and there is no way to enter
another one: vi conceptually turns into a complete different (and
line-based) editor in its command line, called "ex".

In pretty much every editor I know, things like "file entry" and stuff
happens essentially in "transient windows", and you can't leave such a
window before completing things.

Dumbing Emacs' interface down like that does not seem worth the
price.  For example, I quite often do stuff like

C-x C-f ~/junk-2/ M-x make-directory ~/junk-2 RET somefile.tex RET

This is too convenient to abandon, even though I can understand the
choice to not make it the default.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: feature request: indicator of minibuffer-recursion depth

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Dumbing Emacs' interface down like that does not seem worth the
> price.  For example, I quite often do stuff like

I _like_ recursive minibuffers, too
>
> C-x C-f ~/junk-2/ M-x make-directory ~/junk-2 RET somefile.tex RET

[tip on] With ido-mode, 

C-x C-f ~/junk-2 M-m RET somefile.tex RET

does the same thing.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

    > Regarding the proposal for recursive minibuffer commands to
    > quit the outer minibuffer:

    Uh, don't they do that already by default?

Not when you're in the minibuffer.  Then they just signal an error,
and the existing minibuffer level remains active.

    In pretty much every editor I know, things like "file entry" and stuff
    happens essentially in "transient windows", and you can't leave such a
    window before completing things.

We're not talking about such a complex case now.  We're talking about
typing C-x b while you are in C-x C-f.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    Regarding the proposal for recursive minibuffer commands to
    quit the outer minibuffer:

1) Are you referring to David R's suggestion to "automatically quit the
command that's occupying the minibuffer whenever another command requires
it"?

David's example was `C-x b' after `C-x C-f'. I think he was suggesting that
`C-x b' should "take over", so that `C-x C-f' is abandoned (analogous to
`C-x b' exiting incremental search). Is that what you mean too?

Also, I believe that David was talking only about the case where
`enable-recursive-minibuffers' is nil. I don't think he suggested to change
the non-nil behavior. Is your "recursive minibuffer commands to quit the
outer minibuffer" also only for the nil case? (I hope so.)


2) Regarding the non-nil case, there is the question of how to handle
exiting the second command (the one that opens a recursive minibuffer).
Currently, no matter how you exit this recursive-minibuffer command (`RET',
`C-g'), you return to the previous level. It can be convenient sometimes for
a command at a deeper minibuffer level to return its result directly to the
top-level command reading minibuffer input - if the recursive-minibuffer
command knows that that is the right thing to do.

For example, an application I have uses recursive minibuffers to provide
additional match patterns for completion. You invoke a command that reads
another pattern in a recursive minibuffer, and that pattern applies to the
existing set of completion candidates, filtering them further. The effect is
cumulative, so there is no logical need to pass the result up the chain of
recursive minibuffers one by one, to return it to the top level.

Instead of requiring the user to exit from each level in turn (passing along
the same result value), I provide a `catch' within (a redefined)
`completing-read' and `read-file-name' to receive the `throw'n result. So,
`RET' effectively chooses a completion candidate for the top-level command.
(`C-g' cancels only a single minibuffer level, as usual.)

This works whenever `completing-read' or `read-file-name' is used, but
whenever `interactive' is used with a literal spec string (e.g. "fFile: ")
the user must still traverse the recursive minibuffer levels one by one.
Since literal `interactive' specs are handled by C code, my Lisp code has no
way to intervene there.

So, how about adding such a `catch' at a lower implementation level, so it
can be used with literal `interactive' specs also? IOW, implement the
equivalent of this change to `completing-read' (where `old-completing-read'
is the built-in `completing-read'), but at a lower level:

 (catch 'read-top
  (old-completing-read prompt table predicate require-match
                       initial-input hist def inherit-input-method)

Of course, most commands, perhaps even most commands that are used to open a
recursive minibuffer, will never `throw' their result here. But those that
want to could.

Just food for thought, for a possible change after the release.

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

	Regarding the proposal for recursive minibuffer commands to
	quit the outer minibuffer:

    1) Are you referring to David R's suggestion to "automatically quit the
    command that's occupying the minibuffer whenever another command requires
    it"?

    David's example was `C-x b' after `C-x C-f'. I think he was suggesting that
    `C-x b' should "take over", so that `C-x C-f' is abandoned (analogous to
    `C-x b' exiting incremental search). Is that what you mean too?

They are not exactly the same.  Both ideas could be considered.

     It can be convenient sometimes for
    a command at a deeper minibuffer level to return its result directly to the
    top-level command reading minibuffer input - if the recursive-minibuffer
    command knows that that is the right thing to do.

I am completely lost, I don't follow your scenario.
However, since it is complex, it is irrelevant to our
decision about what to do in a simple case.

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    > We can discuss the design after the release, if people think
    > the idea is useful.
    >
    > However, personally I would prefer not to burden the prompt (which can
    > already be quite complex) and instead put the indicator in
    > the mode line somehow.

    The minibuffer does not have a mode line.  And if we want to avoid
    confusion, putting the indicator somewhere far away from the
    minibuffer would not help.

Mode line far away from the minibuffer?  I use a standalone minibuffer frame
(with no mode line, as you point out), and I still wouldn't have trouble
seeing the indicator in the mode line.

    I think the minibuffer prompt a better
    place.  And using the same "recursive" indicator as recursive edits do
    in the mode line is sensible as well in my book.

Anyway, we can figure out the best design after the release. It sounds like
you might be in favor of such a feature, at least.

Re: feature request: indicator of minibuffer-recursion depth

[Stefan Monnier]

> However, personally I would prefer not to burden the prompt (which can
> already be quite complex) and instead put the indicator in the mode line
> somehow.

At startup my Emacs has 1 frame, with 1 (mini) window, and 0 mode-lines.
Also, even after I've opened a few other frames, there's still only ever
1 miniwindow and it has no mode-line next to it (and all the frames with
their mode lines may be iconified or displayed on some other display).

I.e. putting the info on the mode line is not a good idea.


        Stefan

RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

    > However, personally I would prefer not to burden the prompt (which can
    > already be quite complex) and instead put the indicator in
    > the mode line somehow.

    At startup my Emacs has 1 frame, with 1 (mini) window, and 0 mode-lines.
    Also, even after I've opened a few other frames, there's still only ever
    1 miniwindow and it has no mode-line next to it (and all the frames with
    their mode lines may be iconified or displayed on some other display).

Well, then you have the same problem already with recursive edits, no? And
the same problem with other stuff that Emacs puts into the mode line.
Obviously, if someone chooses not to show mode lines, then mode line stuff
is, well, not visible ;-).

A minibuffer recursion-depth indicator (which you seem to favor, in general)
would be a new feature. If you've gotten by so far without any such
indication, and you often do without similar stuff (edit recursion-depth
indicator) that is already in the mode line, then perhaps you'll not miss
it?

My guess is that most people do show mode lines most - nay all - of the
time. I could be wrong.

    I.e. putting the info on the mode line is not a good idea.

for those people who don't display mode lines.

Where would you put the info? So far, the mode line and the minibuffer have
been suggested.

Here's another idea: Use the minibuffer window fringe as a recursion-depth
indicator somehow. (That's probably not a great idea; I'm not sure what uses
the fringe might already serve in the minibuffer, or what uses it might
better serve there in the future.)

To me, it makes sense to put the two recursion-depth indicators in the same
place (mode line).  You would see things like [[[...]]] for recursive edits
and things like {{...}} for recursive minibuffers. If, for some reason, you
entered a recursive minibuffer from a recursive edit, the indicator would be
[{...}]. The opposite order of events would be indicated by {[...]}.

Re: feature request: indicator of minibuffer-recursion depth

[Richard Stallman]

    Recursive-edit depth is indicated in the mode line by bracketing ([...]).
    Being in a recursive minibuffer without knowing it is about as disorienting
    as being in a recursive edit without knowing it. AFAIK, there is no feedback
    regarding minibuffer-recursion depth.

Recursive minibuffers are disallowed by default.  The few commands
that allow them as an exception will not often be used by beginners,
and C-g should get out anyway.

    How do you think put [] on the prompt in minibuffer like:

    [M-x] 
    [[M-x]]
    [[[Find file: ]]] ~/

It could be an improvement, for those who set the variable
to allow recursive minibuffers.  I think this would be better
than putting it in the mode line.  It is more clearly
related to the minibuffer if it is in the minibuffer prompt,
and more visible too.

However, this should wait for after the release.  Can someone
add this to etc/TODO?