From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: when do we remove backward compatibility definitions? Date: Tue, 21 Nov 2017 12:18:41 -0800 Organization: UCLA Computer Science Department Message-ID: References: <834lpncsce.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1511295540 9254 195.159.176.226 (21 Nov 2017 20:19:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 20:19:00 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: sds@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 21 21:18:56 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHF0P-0001nq-SI for ged-emacs-devel@m.gmane.org; Tue, 21 Nov 2017 21:18:53 +0100 Original-Received: from localhost ([::1]:36361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHF0T-0002Ct-Td for ged-emacs-devel@m.gmane.org; Tue, 21 Nov 2017 15:18:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHF0N-0002Co-J0 for emacs-devel@gnu.org; Tue, 21 Nov 2017 15:18:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHF0M-0001z2-Lk for emacs-devel@gnu.org; Tue, 21 Nov 2017 15:18:51 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52002) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eHF0I-0001wF-Vk; Tue, 21 Nov 2017 15:18:47 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1B429161077; Tue, 21 Nov 2017 12:18:43 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4swTMDUJ0o7z; Tue, 21 Nov 2017 12:18:42 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 550E11611D4; Tue, 21 Nov 2017 12:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xyvhha_EbNO1; Tue, 21 Nov 2017 12:18:42 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3ACC1160856; Tue, 21 Nov 2017 12:18:42 -0800 (PST) In-Reply-To: <834lpncsce.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220337 Archived-At: On 11/21/2017 12:03 PM, Eli Zaretskii wrote: > Let's instead solve practical problems with such issues. Are there > any practical problems here? If so, what are they? The practical problem is that when we have cruft in the Emacs source code that makes maintenance harder, we sometimes would like to remove the cruft to simplify maintenance, so long as removing the cruft doesn't unduly affect users (we warned them long ago that the feature was obsolete, etc.). In cases like this it's helpful to have a guideline for when we can simplify the code by removing obsolete cruft. For platform issues (old POSIX platforms that don't support newer POSIX features, for example), the general rule of thumb I use in Emacs and elsewhere is, "If the platform's supplier no longer supports the platform, then Emacs doesn't need to worry about supporting it either." My attempt at writing a guideline for supporting obsolete Emacs features is intended to be along similar lines. It is not meant to be prescriptive and so I shouldn't have used the word "policy" to describe it. It is merely meant as a common-sense guideline for when Emacs features are so obsolete that they can be removed if that simplifies maintenance.