From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Delete variables obsolete since Emacs 23 Date: Wed, 19 Aug 2020 09:39:56 -0400 Message-ID: References: <83r1s4ftc7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7824"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Gregory Heytings To: Gregory Heytings via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 19 15:40:53 2020 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 1k8OKi-0001w9-Oj for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Aug 2020 15:40:52 +0200 Original-Received: from localhost ([::1]:50698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k8OKh-0006l3-R3 for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Aug 2020 09:40:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8OJv-0006ED-Bb for emacs-devel@gnu.org; Wed, 19 Aug 2020 09:40:03 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8175) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8OJs-00029r-IG for emacs-devel@gnu.org; Wed, 19 Aug 2020 09:40:02 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5FFE780C98; Wed, 19 Aug 2020 09:39:59 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B416680C56; Wed, 19 Aug 2020 09:39:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1597844397; bh=bsIr4eRGVqEhMYKpxYcYc+aGaeQS9CO7b4iERUrGbu8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=MrZr0Ar6UNlCaFeO5OunktLJiNaRcYYSZRPJtDqjMr7L1AAr9241WeHlBuy5L+EZ7 E1Es66B7zS/hMnucM2+Hr23pdzDaNiSwzlPEEHoI8fZE3erPcMP9rzcr0bYJzi3G4k k/pQVoM4HHfeBhUbj9ic53faWVDqKzAUopcbvZ9WjYIjU6+K8e/Ieko41du5CVeDE+ hc44BQUc1EEAgkiC9zgWE3l14OCiVT856n3KbhNsVOvmlxeihnDPNIJ05RA6hLhSFt vvt7Nu+BONYud0l2Pfw3XE4hJ9AI48iy5sULQfev7NDxHi6VVRgF7lRiPzk9AxAvdg 3e0xlXIJLMiIA== Original-Received: from alfajor (unknown [45.72.246.108]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B4721202A8; Wed, 19 Aug 2020 09:39:57 -0400 (EDT) In-Reply-To: (Gregory Heytings via's message of "Wed, 19 Aug 2020 08:31:55 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/19 09:10:56 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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:254004 Archived-At: > In that case, would a two-step process not be better? First declaring the > function "obsolete", and when it is known that it will be removed declare > it "pending-removal" with a target major version. I'm not sure it would make much difference to the speed at which people move away from using the obsolete feature (which is really all that matters, in the end). Another approach I toyed with is to change the `make-obsolete*` functions so that they actually *remove* the obsolete feature when used in development builds (i.e. builds with version XXX.0.50). Just like that it's a bit blunt, so it'd have to come with some knobs so the user can ask to disable this for some particular funs/vars, and also so it's only applied when the fun/var has been obsolete for at least 1 (or maybe 2) versions. Stefan