Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings]

> Let me repeat, it is not the content of your posts I find difficult to 
> deal with.  It's their rudeness and aggressiveness.

I think we are miscommunicating.  I honestly don't understand where you 
perceive "rudeness and aggressiveness" in my posts.  I can only say again 
that this was not at all my intention.

> > The old behavior is indeed valuable, if only because it is an old 
> > behavior.
>
> So you're defending old bugs as valuable, simply because they're old. 
> You decline to defend this behaviour on its merits.  Nobody else has 
> done so either, as far as I'm aware.

I did defend it on its merits, multiple times.  What I said did not 
convince you; I should perhaps have written something more detailed, as I 
do below.

I experienced the behavior which surprised you from time to time, and 
found it coherent with the general Emacs behavior.

Let's first define that behavior again: from a user's point of view, in 
Emacs 21 (and possibly earlier) to 27, when minibuffers MB1 to MBn are 
active on a frame F1, and a command that activates the minibuffer is 
started on a frame F2, the minibuffers MB1 to MBn are moved to frame F2, 
and the minibuffer MBn+1 is created.  This behavior happens with 
enable-recursive-minibuffers set to t, either globally or temporarily.

The other possible behaviors are, AFAICS, the ones you try to implement:

1. Either tying each minibuffer to the frame in which it is created.  If 
you tie each minibuffer to the frame in which it was created, there are 
two options:

1.1. Either it becomes possible to interact with them.  From an UI point 
of view, the problem of that behavior is that it is not coherent with 
recursive edits in Emacs, of which recursive minibuffers are an instance. 
When you enter a recursive edit you cannot act on the non-recursive edit 
level or on the previous recursive edit levels anymore, you first have to 
leave the current recursive edit.  As the Emacs manual explains, recursive 
edits "constrain you to go back in a particular order---from the innermost 
level toward the top level."  IOW, that behavior would violate the general 
recursive editing constraint.

1.2. Or you make sure in one way or another that it is not possible to 
interact with them, which means that the user sees a minibuffer that it 
cannot use (for instance by clicking on it).  From an UI point of view, 
this would be counter-intuitive; I don't know any other UI element that is 
displayed by Emacs and that you cannot interact with.

2. Or always moving the minibuffers to the currently active frame.  From 
an UI point of view, the problem is that such a movement is, in most 
cases, gratuitious: when you start a command in a frame and switch to 
another frame, in most cases this switch is a temporary one (for example 
to check the documentation of the command you just started), and what you 
intend to do is to switch back to the frame in which you started the 
command to complete it.

The old behavior, which you despise, is not "chaotic" (see the definition 
of that word in Wordnet: "completely unordered and unpredictable and 
confusing", or in Wiktionary: "extremely disorganized"), it is 
well-defined, and it is a reasonable solution which avoids (at least) 
these three problems.  And it has worked well for virtually all Emacs 
users in the last twenty years.

There is, in fact, a fourth possible behavior, which AFAICT has not been 
discussed in this thread:

1.3. Tying each minibuffer to the frame in which it is created, but make 
it invisible when a recursive minibuffer is entered in another frame, and 
visible again when that recursive minibuffer is left.  The problem I see 
in this potential behavior is that, upon leaving the recursive minibuffer, 
the user would have no indication that another minibuffer is still (or 
rather, again) open in another frame, waiting for their input.  This is 
yet another problem that the old behavior avoids.