Miles Bader <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (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 _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
