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: Confused by y-or-n-p Date: Wed, 06 Jan 2021 09:41:09 +0000 Message-ID: References: <834kkcr1eo.fsf@gnu.org> <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> <83mtxqcauz.fsf@gnu.org> <83turva0y2.fsf@gnu.org> 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="36358"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: rudalics@gmx.at, Eli Zaretskii , juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 06 10:43: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 1kx5LK-0009Ib-Sc for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Jan 2021 10:43:02 +0100 Original-Received: from localhost ([::1]:53930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kx5LJ-0005mY-SS for ged-emacs-devel@m.gmane-mx.org; Wed, 06 Jan 2021 04:43:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45224) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kx5Jl-0004Uv-5W for emacs-devel@gnu.org; Wed, 06 Jan 2021 04:41:25 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:51153) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kx5Ji-0001Hi-Sm for emacs-devel@gnu.org; Wed, 06 Jan 2021 04:41:24 -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 1069fCLb026184 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 6 Jan 2021 09:41:12 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 1069fn19008998; Wed, 6 Jan 2021 09:41:49 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=unavailable 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:262582 Archived-At: >> I agree with you that this is already happening in the vast majority of >> cases, so why would it be problematic to make this a rule, that in >> principle any change to Emacs' behavior should provide a way to >> re-enable the old behavior? IIUC that's all Richard wants. Of course >> that rule would not apply to bugfixes, and exceptions would be possible >> with the explicit approval of a maintainer. > > The problem is that I disagree with your "Of course": the whole > difficulty is to decide which change falls in this category. > > The problem is not that we don't follow the rule or that we don't have > such a rule. It's that there's no hard-and-fast way to decide where > that rule should apply: it's a judgment call and often this call is > non-trivial (what one person calls "feature" qualifies as "bug fix" for > another, what should be a cosmetic change may end up unexpectedly > changing behavior), which is why sometimes it takes feedback from users > to realize we got it wrong. > A rule is not a mathematical law, it's an action guideline. Such a rule would avoid having developers start working on something thinking that scratching the current state of affairs to create something they believe is better without thinking about backwards compatibility is okay. This does happen, and this can lead and does lead to unnecessary disputes (one is underway), that could be avoided with such a rule. By the way, the feedback in this case came from Richard, who wanted the old behavior back, and he got it back in a few days. I'm curious whether this would have happened if the feedback had been sent by a random user.