[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: feature request: indicator of minibuffer-recursion depth
From: |
Drew Adams |
Subject: |
RE: feature request: indicator of minibuffer-recursion depth |
Date: |
Sat, 5 Aug 2006 15:04:16 -0700 |
From: Kim F. Storm [mailto:address@hidden
Miles Bader <address@hidden> 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?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: feature request: indicator of minibuffer-recursion depth,
Drew Adams <=