[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stop frames stealing eachothers' minibuffers!

From: Gregory Heytings
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Wed, 06 Jan 2021 00:14:45 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]