emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature request: indicator of minibuffer-recursion depth


From: David Reitter
Subject: Re: feature request: indicator of minibuffer-recursion depth
Date: Wed, 15 Mar 2006 19:18:08 +0000

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]