From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Wed, 06 Jan 2021 00:14:45 +0000 Message-ID: References: <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13016"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 06 01:17:40 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 1kwwWC-0003Ge-Rl for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Jan 2021 01:17:40 +0100 Original-Received: from localhost ([::1]:43474 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwwWB-0002ek-Ro for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 19:17:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwwTV-0000G8-1i for emacs-devel@gnu.org; Tue, 05 Jan 2021 19:14:53 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:51996) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwwTS-0003kU-RO for emacs-devel@gnu.org; Tue, 05 Jan 2021 19:14:52 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 1060Elt9025159 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 6 Jan 2021 00:14:47 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 1060FQQK014424; Wed, 6 Jan 2021 00:15:26 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org 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_PASS=-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:262554 Archived-At: > > 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.