From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Tue, 31 Aug 2021 22:37:43 +0300 Message-ID: <8335qps8vs.fsf@gnu.org> References: <87h7fcnmq0.fsf@posteo.net> <83tujbqg4j.fsf@gnu.org> <46353190-1190-495f-b15e-22980159b3ab@yandex.ru> <83y28mp0rb.fsf@gnu.org> <51a363db-fde7-791d-cf8d-98ac601d62ee@yandex.ru> <57ca4d78-2339-201d-edce-678c9b003a99@yandex.ru> <83bl5dsh8b.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1456"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, danflscr@gmail.com, rms@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, john@yates-sheets.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 31 21:39:03 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 1mL9b5-00006m-Kb for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Aug 2021 21:39:03 +0200 Original-Received: from localhost ([::1]:55476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mL9b4-0004w6-Fb for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Aug 2021 15:39:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mL9a3-0003dx-8U for emacs-devel@gnu.org; Tue, 31 Aug 2021 15:37:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50632) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mL9a1-0008HD-OY; Tue, 31 Aug 2021 15:37:57 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3807 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mL9Zv-0004IY-Jd; Tue, 31 Aug 2021 15:37:51 -0400 In-Reply-To: (message from Dmitry Gutov on Tue, 31 Aug 2021 22:17:10 +0300) 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:273620 Archived-At: > Cc: rms@gnu.org, danflscr@gmail.com, philipk@posteo.net, > monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Tue, 31 Aug 2021 22:17:10 +0300 > > Or as I've been saying, we love additions but hate changes. Emacs is an old and _stable_ package. "Stable" means just that: features burned into users' muscle memory don't just change every weekend. So we do it slowly, cautiously, and preferably via opt-in features, because we respect our users and their habits. It is maddening to have to re-learn your editor just because you've upgraded. > we could start a discussion into changing this, or at least > instituting some procedures for making important > non-backward-compatible changes. We _have_ procedures for making backward-incompatible changes, and we use those procedures all the time. > Nobody with power to make decisions has shown any interest, however. Please forgive me the lecture that you don't need: talking never moves anything in Emacs, never did, never will. Change in Emacs comes when motivated individuals sit down and do the work. If someone presents the code to make some backward-incompatible change in a way that leaves it opt-in, the resistance is likely to be much lower than it may seem when such changes are just "discussed". For the same reason, it is hard to show interest in an Nth theoretical discussion that never results in any code; by contrast, having a code presented to us _requires_ "The Powers That Be" to make decisions, whether they want it or not. Backward-incompatible changes in the _defaults_ take much longer and might be met with more resistance, that's true. But this is a feature in Emacs; see above. My advice is not to insist on having each incompatible change to become the default the moment it is coded: it will in the long run make such changes much easier to introduce, and everyone wins.