Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>]

>
> I do still find his manner of expression difficult to deal with.
>

I apologized once, I will not do this again.  I've read my previous mails 
to you again, and don't see anything wrong in what I said.

>> It did not "turn out", I explained in detail that the behavior that 
>> Alan considered buggy was not at all buggy before he started working on 
>> this.
>
> I don't think you "explained" at all, and certainly not before I started 
> working on it - I initiated the discussion with a proposed patch so as 
> to minimise the risk of just wasting people's time with bikeshedding.
>

I did tell you that the behavior you found incoherent was not, and that 
this behavior was an old one dating back to Emacs 21 at least, three days 
before you initiated the discussion.  That happened in the "New 
multi-command facility displays in the wrong echo area" thread.

>
> You keep referring to an "old behaviour" that I removed, as though there 
> were something coherent, something valuable, something worth keeping. I 
> don't think there's anything of the kind.  I think the former behaviour 
> just happened by accident as a result of people working on other things, 
> and nobody consciously made it happen.  I am now consciously trying to 
> fix it.  If you've argued for an old behaviour on its merits, possibly 
> in the thread "stealing eachother's minibuffers", could you perhaps 
> point out the place in that thread, so that I can read it again.
>

The old behavior is indeed valuable, if only because it is an old 
behavior.  Emacs' stability is important.  I don't see why the burden of 
proof that a behavior about which virtually no Emacs user in the last 
twenty years complained is not a bad one would be on me.

You believe that the old behavior is chaotic and happened by accident, but 
it is also possible that your belief is wrong.

The old behavior is, at the very least, not chaotic, it is well defined: 
from a user's point of view, when a recursive minibuffer is entered in a 
frame F2 while one or more recursive minibuffers are active on a frame F1, 
these minibuffers are moved from frame F1 to frame F2 before the new 
minibuffer is created.  Saying that this is not an "ad hoc unsystematic 
mess" is not expressing an opinion among other opinions.

>> What could have been done instead is to add some new code next to the 
>> existing one to conditionally provide a new behavior,
>
> That could not have been done, due to the state of the code in 
> minibuf.c, in particular, due to the lack of any coherent "existing 
> behaviour".

I looked at your 2ecbf4cfae7, c3edaa55249 and 6e469709c55 commits, and at 
your patch, and I don't see why the old code could not continue to exist 
next to the new one.