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: Confused by y-or-n-p Date: Mon, 04 Jan 2021 16:59:57 +0200 Message-ID: <8335zgd9xu.fsf@gnu.org> References: <834kkcr1eo.fsf@gnu.org> <43b24209-fa65-0e26-7cbd-f99175a7ffd8@gmx.at> <87wnx7j5is.fsf@mail.linkov.net> <83im8qnyca.fsf@gnu.org> <83bleinmse.fsf@gnu.org> <56435592-d2d0-5fb6-977f-01e1931da835@gmx.at> <87k0t38g1z.fsf@mail.linkov.net> <83czyvkts6.fsf@gnu.org> <87bleetirr.fsf@mail.linkov.net> <87y2hhri3n.fsf@mail.linkov.net> <83pn2tkfg8.fsf@gnu.org> <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, larsi@gnus.org, emacs-devel@gnu.org, drew.adams@oracle.com, juri@linkov.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 16:02:05 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 1kwRMz-0002Bt-Tc for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 16:02:05 +0100 Original-Received: from localhost ([::1]:42760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwRMy-0003s9-Ro for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 10:02:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwRLu-0002wN-QO for emacs-devel@gnu.org; Mon, 04 Jan 2021 10:00:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35912) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwRLt-0001tP-L5; Mon, 04 Jan 2021 10:00:57 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2295 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwRL4-00074A-T1; Mon, 04 Jan 2021 10:00:08 -0500 In-Reply-To: (message from Richard Stallman on Mon, 04 Jan 2021 00:16:55 -0500) 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:262429 Archived-At: > From: Richard Stallman > Cc: rudalics@gmx.at, larsi@gnus.org, juri@linkov.net, > drew.adams@oracle.com, emacs-devel@gnu.org > Date: Mon, 04 Jan 2021 00:16:55 -0500 > > > When this happens in a released version, the resistance is justifiably > > stronger. But those cases should be (and are, IME) very rare. > > My point is that they are not so rare -- there is a systematic tendency > for that to happen. What is the basis for your impression that such a tendency exists? Any cases besides this single one? "Systematic" is a pretty strong word in this context, it would mean we make backward-incompatible changes basically all the time. I don't have such an impression. In fact, we are frequently accused in the opposite: that we change the defaults too slowly. > I am proposing a systematic way to make them less likely, by helping > people take notice that a UI change is being proposed, so they can > object quickly. We need to consider the cost of your proposal as well as its benefits. I think the costs are too high, given the scarcity of the problems the proposal aims at fixing, the significant effort it will impose on the head maintainers, and the adverse effect on development pace. > > situation is actually the exact opposite: changes are being discussed > > "to death" and sometimes never implemented due to controversy. > > My proposal will help with that problem too. Instead of waiting for a > resolution of the dispute, we should install the change with a user > option variable to enable the new behavior. That is already happening where the change seems to be controversial or a too radical departure from long-time behavior. > That bypasss the dispute. It doesn't. At best, it just changes the subject of the dispute to whether the new behavior should be the default. At worst, people keep arguing about the necessity of the change, even though it can be disabled. I didn't bring up this particular aspect to complain about it, because complaining about it in an open project where development discussions are public is pointless: anyone can start a discussion about any issue related to Emacs, and we allow and encourage that as part of our policy. I brought that up to point out that some -- quite a few -- opine that we have too many discussions already. Which in my view means we have a balanced situation: some think we have too few discussions, others think we have too many. Increasing the discussion will thus tilt the balance -- not necessarily for the better.