Re: feature request: indicator of minibuffer-recursion depth

[David Reitter <david.reitter@gmail.com>]

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.