help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: C-x C-f in two frames -> "user minibuffer while in


From: don provan
Subject: Re: C-x C-f in two frames -> "user minibuffer while in
Date: 04 Jul 2005 00:52:44 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Miles Bader <miles@gnu.org> writes:

> dkcombs@panix.com (David Combs) writes:
> >>If you set enable-recursive-minibuffers to t it works.
> >>(setq enable-recursive-minibuffers t)
> >
> > That is, what *disadvantages* from setting it on?   What bewares
> > of having it on?
> 
> It apparently confuses beginners greatly when they accidentally end up
> with a recursive minibuffer.

Apparently? You really mean to say it's never confused you? I'm
impressed.

Anyway, I'm sure that's the main reason. Another reason, I would
guess, is that there are a few bugs. Every once in a while, I run into
cases where the wrong key map is active or the mini-buffer is
prompting for one thing but doing completion for another.

But even so, I agree that most experienced Emacs users would probably
prefer recursive minibuffers enabled, especially once they get used to
it.

The original question sounds like the user expected each frame to have
its own, independent minibuffer. Even with minibuffers enabled, the
minibuffers in each frame are tied together so that, if I understand
things correctly, there's really only one recursive stack, and the
current top interaction typically attached to the current frame.

Also, I don't think a single command such as ^x^f can recurse on
itself, as would be required in the original example. If you ^x^f and
then switch to another window and do a second ^x^f, as far as I can
tell, the first ^x^f is always aborted. I think the original poster
expected to be able to do two file-find's at the same time, one in
each minibuffer of the two frames.

-don


reply via email to

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