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 20:15:45 +0200 Message-ID: <83ble4bmb2.fsf@gnu.org> References: <834kkcr1eo.fsf@gnu.org> <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> <83wnwsbuwp.fsf@gnu.org> <87mtxo4tph.fsf@gnus.org> <83eej0bnsd.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24871"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, juri@linkov.net, rudalics@gmx.at, stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org, drew.adams@oracle.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 19:21:04 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 1kwUTX-0006IL-5s for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 19:21:03 +0100 Original-Received: from localhost ([::1]:40768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwUTW-0005pE-7Q for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 13:21:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48400) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwUOn-0001vr-VM for emacs-devel@gnu.org; Mon, 04 Jan 2021 13:16:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41069) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwUOl-0004jK-VX; Mon, 04 Jan 2021 13:16:08 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2451 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwUOa-0001wd-AR; Mon, 04 Jan 2021 13:15:59 -0500 In-Reply-To: (message from Stefan Monnier on Mon, 04 Jan 2021 13:02:15 -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:262471 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, stefankangas@gmail.com, rms@gnu.org, juri@linkov.net, > rudalics@gmx.at, emacs-devel@gnu.org, drew.adams@oracle.com > Date: Mon, 04 Jan 2021 13:02:15 -0500 > > I was thinking of changing `make-obsolete` and friends so they > undefine (or refrain from defining) the function/variable. They could > do so by testing `emacs-version` (or some other way to detect the > `master` code) along with some extra config vars (e.g. a var to force > the behavior globally on way or the other or only for some > functions/variables). That's fine, but then such a mechanism can handle only a small portion of the changes that can be perceived as incompatible with past behavior. For example, the change which started this thread cannot be easily handled that way, because it is not about making something obsolete. Most of the changes we are talking about don't obsolete anything. We should also consider the effects of this on code readability. It is unexpected to have make-obsolete undefine its subject, let alone do it or not depending on some under-the-hood magic.