Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Wed, Jan 06, 2021 at 00:14:45 +0000, Gregory Heytings wrote:


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

Let me repeat, it is not the content of your posts I find difficult to
deal with.  It's their rudeness and aggressiveness.  If you'd said what
you had to say in a gentle and co-operative manner, as for example Martin
does when disagreeing with me, I wouldn't now be asking myself if
responding to your posts is worth it at all.
 
> >> 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 "told" me, and seem to expect that I accept what you say without
question, as though you were some sort of guru.  On this particular
point, you seem to be mistaken, or at the very least in a minority of
one.

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

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.

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

Ratchet your level of abstraction down a notch or two, please.  We're
talking about a particular bit of behaviour, which if somebody proposed
as new on emacs-devel would get rejected out of hand, and indeed
ridiculed.  I was asking you to provide me with missing information,
something which might persuade me that this behaviour was less chaotic
and more systematic than it outwardly appears.

Emacs's "stability", in the way you seem to mean it would prevent new
developments and old bug fixing from happening.

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

Not really.  You're not telling me somebody sat down at his computer one
day, and said "hey, it'd be a great idea if the minibuffer changed frames
when and only when a recursive minibuffer were opened on another frame"?
Be serious, such an abstruse "design" can only have arisen by accident.

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

I am the person doing the work, not you.

-- 
Alan Mackenzie (Nuremberg, Germany).