bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

[Drew Adams]

>  >> and probably get some very convoluted semantics wrt
>  >> the selected frame.
>  >
>  > =?
> 
> Which one is the selected frame when I have a standalone minibuffer
> frame and access the Minibuf entry in the menubar of another frame?

I don't know, here.  But I do use a standalone minibuffer all the time and I
click etc. things in other frames during minibuffer input (e.g. using
completion).  (This is on Windows; dunno whether that makes a difference.)

There is a difference (as I'm sure you know) between a frame having the focus
and a window being selected.

Typically during minibuffer input (e.g. using completion) the minibuffer window
is selected, at least at some point(s), but the frame that has the focus remains
the frame that had the focus before calling `completing-read' (or whatever).

That doesn't prevent things working as expected.  Activating the minibuffer does
not move the frame focus to the minibuffer frame, I believe.  And a user can
still interact with other frames during this.  But yes, it can happen that some
user actions during input will cause the focused frame to change.

(I'm going on memory here; I don't claim 100% accuracy for this description.)

So I would agree that it might be tricky or that we don't (that is, I don't)
know a priori what would happen wrt choosing a menu item in another frame's menu
bar.  But presumably using the menu bar of the frame with the focus (which is
not the minibuffer frame) should not have any such focus-change effect - that
would be my guess anyway.

> Or do you mean you don't care?

My `=?' meant "what do you mean by that?"  What convoluted semantics do you
foresee?  That's all I meant.