From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Thu, 7 Jan 2021 13:27:04 +0000 Message-ID: References: <20201125210947.GB8228@ACM> <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7801"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 07 14:28:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxVLN-0001oA-VS for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 14:28:49 +0100 Original-Received: from localhost ([::1]:39110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxVLN-0001sG-1k for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 08:28:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxVJq-0001Ip-7a for emacs-devel@gnu.org; Thu, 07 Jan 2021 08:27:14 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:48995 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kxVJm-0000Db-H0 for emacs-devel@gnu.org; Thu, 07 Jan 2021 08:27:14 -0500 Original-Received: (qmail 24022 invoked by uid 3782); 7 Jan 2021 13:27:05 -0000 Original-Received: from acm.muc.de (p4fe15aa4.dip0.t-ipconnect.de [79.225.90.164]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 07 Jan 2021 14:27:04 +0100 Original-Received: (qmail 7175 invoked by uid 1000); 7 Jan 2021 13:27:04 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262672 Archived-At: 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).