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

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

[David Reitter]

I don't know if this is a bug or not, so I'll post it here:

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"

This happens with standard settings, on the GNU/Linux port as well as  
on Carbon, no matter what display-buffer-reuse-frames is.

Is that a bug?

D

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

[Peter Dyballa]

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 
...)

--
Greetings
                                  <]
    Pete      o        __o         |__    o           recumbo
     ___o    /I       -\<,         |o \  -\),-%       ergo sum!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________

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

[Toto]

In article <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org>, Peter Dyballa <Peter_Dyballa@Web.DE> 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.
 
> --
> Greetings
>                                   <]
>     Pete      o        __o         |__    o           recumbo
>      ___o    /I       -\<,         |o \  -\),-%       ergo sum!
> ___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________
> 
> 
> 
-- 
				[ Toto ]

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

[David Combs]

In article <A$E7Qq1ywbQg@ludens>, Toto <bago@ludens.elte.hu> wrote:
>In article <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org>, Peter Dyballa <Peter_Dyballa@Web.DE> 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

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

[Miles Bader]

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.

For instance, a common scenario is something like:  you click the mouse
in a buffer while the minibuffer is active, then re-invoke your command
thinking the minibuffer input had been aborted [but of course it wasn't,
so you end up with recursive minibuffers].  If you have a good mental
model of how Emacs works, you'll recognize this situation and deal with
it properly, but many people don't.

-Miles
-- 
I'd rather be consing.

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

[don provan]

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

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

[Miles Bader]

don provan <dprovan@comcast.net> writes:
>> 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.

Well of course I occasionally get tripped up, but I usually quickly
realize what's going on and fix it.

-Miles
-- 
Would you like fries with that?

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

[don provan]

Miles Bader <miles@gnu.org> writes:

> don provan <dprovan@comcast.net> writes:
> >> 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.
> 
> Well of course I occasionally get tripped up, but I usually quickly
> realize what's going on and fix it.

(*whew*) You had me worried, there. I was suspecting you might be an
alien invader or something.

Anyway, as I say, I agree it's a win. It's just undeniably confusing,
not merely "apparently" confusing. Like when you recurse to do a
second operation, but then you have to actually do something to get
yourself back into the minibuffer to resume -- or even abort! -- the
original operation. You have to get very comfortable switching between
windows before that seems at all natural. What's more, the minibuffer
at times gives you no clue there's previously started command to
return to.

Has anyone come up with any ways the recursive commands could be
better, or is it pretty much accepted that there's nothing that could
be done to improve them?
-don

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

[Thien-Thi Nguyen]

don provan <dprovan@comcast.net> writes:

> Has anyone come up with any ways the recursive commands could be
> better, or is it pretty much accepted that there's nothing that could
> be done to improve them?

one idea is to modify `mode-line-format' to indicate presence, level,
or stack contents, of recursion.

  presence:       R
  level:          RRR   (or maybe R3)
  stack contents: (find-file find-file find-file)

alternatively, borrow something from the recursive editing indicator
(normally square braces around the major and minor mode info).

nothing is univerally "pretty much accepted" (except death and taxes,
but i hear emacs and the fsf avoid these, respectively, somehow :-).

thi

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

[Drew Adams]

    > Has anyone come up with any ways the recursive commands could be
    > better, or is it pretty much accepted that there's nothing that could
    > be done to improve them?

    one idea is to modify `mode-line-format' to indicate presence, level,
    or stack contents, of recursion.
      presence:       R
      level:          RRR   (or maybe R3)
      stack contents: (find-file find-file find-file)
    alternatively, borrow something from the recursive editing indicator
    (normally square braces around the major and minor mode info).

One problem is that such mode-line changes are not very noticeable. Now that
we can easily change the mode-line face, that could be used to draw more
attention to a recursive edit. Face change, especially background, is more
noticeable than simply adding/changing mode-line text, and if the
color-change is well chosen, it need not be intrusive/annoying.

I do something similar: change the minibuffer (not the mode-line)
background. Library `oneonone.el'
(http://www.emacswiki.org/elisp/oneonone.el) sets up a dedicated minibuffer
frame, and that frame's background is changed dynamically to indicate the
current state. There are 3 states: normal (inactive), awaiting user input
(active), and isearch (searching). There is no state specifically for
recursive edit (but there could be); recursive edit is reflected by the
"active" state. "Active" essentially means "not top-level".

See http://www.emacswiki.org/cgi-bin/wiki/Dedicated_Minibuffer_Frame for an
explanation and screenshots. Whenever you are in a recursive edit, not only
does the mode-line indicate this (by surrounding the mode name with
brackets, as usual: []), but the minibuffer frame background color is also
changed to indicate the "active" mode. You normally only see this color
minibuffer when Emacs is expecting input, so, if you continue to see it, it
acts as a clue to look for the brackets in the mode-line that indicate a
recursive edit. HTH, Drew.

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

[David Kastrup]

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.
>
> For instance, a common scenario is something like:  you click the mouse
> in a buffer while the minibuffer is active, then re-invoke your command
> thinking the minibuffer input had been aborted [but of course it wasn't,
> so you end up with recursive minibuffers].  If you have a good mental
> model of how Emacs works, you'll recognize this situation and deal with
> it properly, but many people don't.

Most common problem for me is
M-x M-x
accidentally (probably by autorepeat).  Getting out of those can be
fun, in particularly if you change windows manually afterwards (Esc
Esc Esc helps somewhat for that case).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: C-x C-f in two frames -> "user minibuffer while in minibuffer": Bug?

[Drew Adams]

    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"

    This happens with standard settings, on the GNU/Linux port as well as
    on Carbon, no matter what display-buffer-reuse-frames is.
    Is that a bug?

Others have explained what's happening wrt minibuffer input. Here's some
more info that might help:

The *Completions* buffer is a bit special, in that its input is directed to
the minibuffer. When it is in a separate frame, the frame focus needs to be
redirected to the minibuffer explicitly, I've found. I do this:

;; Use `my-display-*Completions*-frame' to display *Completions* buffer
(add-to-list
  'special-display-buffer-names
  (list "*Completions*" 'my-display-*Completions*-frame))

(defun my-display-*Completions*-frame (buf &optional args)
  "Display *Completions* buffer in its own frame.
`special-display-function' is used to do the actual displaying.
Completion input events are redirected to `my-minibuffer-frame'."
  (let (return-window)
    (setq return-window
          (select-window (funcall special-display-function buf args)))
    (raise-frame)
    (redirect-frame-focus (selected-frame) my-minibuffer-frame)
    return-window))

The key line is the second-to-last: redirect-frame-focus.

The value of variable `my-minibuffer-frame' is a standalone minibuffer
(only) frame. (For the complete code, see
http://www.emacswiki.org/elisp/oneonone.el. See also
http://www.emacswiki.org/elisp/elect-mbuf.el for code that removes the
*Completions* frame when you are done with it.)

HTH,

  Drew

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

[LENNART BORGMAN]

From: don provan <dprovan@comcast.net>

> 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.

Would not the behaviour the original poster expected be normal on a windowing system?

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

[don provan]

LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:

> From: don provan <dprovan@comcast.net>
> > 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.
> 
> Would not the behaviour the original poster expected be normal on a
> windowing system?

Yes, I suppose it would be, and I'm not sure I'd want to defend
Emacs's behavior too strongly. But Emacs is, I would claim, primarily
a keyboard entry based editor, so the emphasis is on a single point of
data entry rather than visual consistency. So I'm not too distressed
by the inconsistency with typical windowing systems, although it
wouldn't surprise me if the reasons for being that way are primarily
historical. There are some weird and wonderful things going on in the
minibuffer, so I wouldn't want to speculate on whether it would be
reasonable to approach them differently.

-don