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: Confused by y-or-n-p Date: Mon, 4 Jan 2021 12:34:56 +0000 Message-ID: References: <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> 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="25595"; 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 Mon Jan 04 13:36:13 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 1kwP5p-0006ZX-9s for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 13:36:13 +0100 Original-Received: from localhost ([::1]:57604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwP5o-0004wN-Ch for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 07:36:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47792) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwP4f-0004K8-Mo for emacs-devel@gnu.org; Mon, 04 Jan 2021 07:35:01 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:25411 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kwP4d-0003Qg-9X for emacs-devel@gnu.org; Mon, 04 Jan 2021 07:35:01 -0500 Original-Received: (qmail 50913 invoked by uid 3782); 4 Jan 2021 12:34:56 -0000 Original-Received: from acm.muc.de (p4fe15a93.dip0.t-ipconnect.de [79.225.90.147]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Jan 2021 13:34:56 +0100 Original-Received: (qmail 10713 invoked by uid 1000); 4 Jan 2021 12:34:56 -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:262422 Archived-At: Hello, Gregory. On Mon, Jan 04, 2021 at 11:35:19 +0000, Gregory Heytings via Emacs development discussions. wrote: > >> That's not correct, see for example the thread "Stop frames stealing > >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' > >> minibuffers, which are arguably a central piece of Emacs' UI, is being > >> modified on the pretext that it is "unsystematic", without any > >> argument, and in spite of the fact that hundreds and thousands of users > >> have been using it without complaining about that supposed > >> "unsystematicity". > > There has been argument, on that other thread, which you have taken part > > in, and which now extends to nearly 200 posts. > I haven't seen a single argument in that thread to remove the current > behavior. I've only seen an argument that you (and only you AFAICS) don't > like it. I suggest you reread that thread, long though it is, with some care. There were strong arguments expressed there, for improving the then current behaviour. > > That few people complained about the old behaviour is not a strong > > argument against improving it. Many improvements to Emacs are made > > without being prompted by widespread complaints. > I never ever objected the idea of improving the minibuffer behavior. I > strongly objected the idea of removing its longstanding behavior. As I have just said, your objections have been taken into account and acted upon. I don't really want to get drawn here into detailled discussion which really belongs on that other thread, but would point out that that "longstanding behaviour" which you seem so attached to appears to be an ad hoc unsystematic mess resulting from a lack of systematic attention. I have now given it that attention. > >> I repeatedly explained that the old behavior should remain available. > >> Initially the change explicitly removed the old behavior: "The old > >> [behavior] is no longer available." The latest patch sent yesterday, > >> only promises to "approximate" the old behavior. > > It would thus appear that you are an "important enough person". > No, quite the contrary. Forgive me if I become uncustomarily blunt and personal, but it seems you are determined to find the worst possible interpretation of everything, and your replies to so many posts take on an unusually negative tone. I put the old behaviour back specifically to please you and others like you, yet your reaction, rather than to thank me, is to criticise that it is "only an approximation". And that before you have even tried it out. Dealing with such negativity is an emotionally draining experience for me, and I suspect I am not alone here. One way of coping with this would be to ignore your posts entirely, but I don't want to do that. Would you please try to be more positive in your posts, and try to work together with people to achieve goals, rather than antagonising them. Thanks! > > I put the old behaviour back as a result of your representations, > > despite not understanding why anybody might want it. > That's the problem I mentioned in my other email: "because [some users] > use Emacs in a way that was not envisioned by the developer who > implemented the UI change, and that this UI change breaks their > configuration, which relied on the old behavior". We cannot know what > kind of exotic things people do with Emacs, and the only way to ensure > that it is stable is to keep the old behavior alongside the new one, at > least for some time. Some time later (one or two major releases later, > say) the old behavior can of course be deprecated, with a target release > when this will happen. That gives users the time to adapt their libraries > and configurations. But all of a sudden removing the old behavior and > installing a new one is IMO wrong. The old "behaviour" seems to be an ad hoc unsystematic mess, not worthy even of being called a behaviour. > > However, since I've tidied up the C code appreciably, I cannot guarantee > > that this behaviour is 100% the same as the old, hence the use of the > > word "approximate". > > Have you tried this patch out, yet? If there is anything in the > > "approximation" which is not close enough, perhaps you could point out > > what, so that I might fix it. Thanks! > Not yet, I'll do that, but can't promise when. But the problem is that I > am now, and everybody else is now, in a situation where we have to spend a > lot of time testing various combinations of commands and to describe what > doesn't work anymore, which inevitably leads to very long and boring mails > and discussions. How is that a problem? Nobody is forcing you into such discussions. At the cutting edge of development, there are bound to be new things, there are bound to be old things let go, and there are bound to be controversies. That is the very essence of development. People are grateful for the feedback you give, but nobody is forcing you into doing anything. -- Alan Mackenzie (Nuremberg, Germany).