In article <[EMAIL PROTECTED]>, Toto <[EMAIL PROTECTED]> wrote: >In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes: >> Am 08.06.2005 um 15:18 schrieb David Reitter: >> >>> If I open a second frame, then do C-x C-f in one of them and press tab >>> so that the window is split and I get a *Completions* buffer in one >>> frame, and when I then select the second frame and do a C-x C-f there, >>> I don't get another *Completions* buffer there, but an error message >>> that appears in the first frame: >>> >>> "Command attempted to use minibuffer while in minibuffer" >>> >> >> No, that's definitely no bug! There is in the first frame minibuffer >> waiting for your input. And since there is only one such thing, yet, >> you can't use it for something different somewhere else. >> >> I think too it would be a nice enhancement if every frame would have >> its own minibuffer. I remember that from time to time I had to use more >> than one Emacs running to get things together for an input to >> minibuffer (could have sorted this out in scratch buffer -- but then I >> would have needed to remember how I made minibuffer awaiting my input >> ...) > >If you set enable-recursive-minibuffers to t it works. >(setq enable-recursive-minibuffers t) > >So that's definitely no bug, indeed. >
Sounds good -- but if it were good, why isn't "on" the default? That is, what *disadvantages* from setting it on? What bewares of having it on? Thanks, David _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
