Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets <andreyk.mad@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>>>> Does anyone else think this is common usage, to have a minibuffer-only frame
>>>> while other frames also have minibuffers?
>>>
>>> FWIW, I've never seen it in the wild (I've seen mixes of frames with
>>> and without minibuffers, but when there is a minibuffer-only frame
>>> never seen it accompanied with other frames-with-minibuffer, except for
>>> frames on other terminals).
>> 
>> I don't sure what the "in the wild" means, but I know at least two
>> packages that shows minibuffer-only child frame on reading user input:
>
> I didn't ask if this was possible, or used, I asked if such usage is
> common.

I don't think such usage is common nowadays.  Maybe someday it would
sound like "minibuffer-only frame while other frames have echo areas"
and then it would be more commonly used IMO.

> It is clear that we cannot find a default that will fit all
> the uses, but we should have the default that works well in common use
> cases.

Totally agree.  Just thought that the existing behavior is common
enough.

Don't you the think new behavior may be confusing?  The old behavior was
like "Oh, I left the minibuffer in that frame; OK, I need to switch to
that frame and complete the task".  And the new one is like "Oh, the
minibuffer is on active frame, cool! But wait, where is the results of
my eval?" because in 'emacs -Q':

C-x 5 b foo RET bar M-: (buffer-string) C-x 5 o C-x o RET

Seems like the 'buffer-string' is evaluated in the *scratch* buffer, but
it is not.