From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: RCS, again: another removed functionality: undo last-checkin Date: Thu, 1 Oct 2015 16:55:33 -0700 (PDT) Message-ID: <52e0ce3a-c64a-4c17-9e26-0fab7658f5dc@default> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <87eghsfd3m.fsf@fencepost.gnu.org> <83k2rknr2c.fsf@gnu.org> <87mvwellmg.fsf@uwakimon.sk.tsukuba.ac.jp> <56023A6C.3020302@yandex.ru> <5602BE3E.1050009@yandex.ru> <5602C4DE.8020105@yandex.ru> <560B4899.2070708@yandex.ru> <83y4fobegc.fsf@gnu.org> <560BC73C.4040403@yandex.ru> <83d1x0atb2.fsf@gnu.org> <560C9EDA.3040207@yandex.ru> <83vbar9hv3.fsf@gnu.org> <560D2CFD.50702@yandex.ru> <83a8s2agar.fsf@gnu.org> <560D6F13.3090005@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443743767 6484 80.91.229.3 (1 Oct 2015 23:56:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 23:56:07 +0000 (UTC) Cc: stephen@xemacs.org, dak@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 01:55:54 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zhnha-0005dh-CB for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 01:55:54 +0200 Original-Received: from localhost ([::1]:56696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhnhZ-00068D-Bd for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 19:55:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhnhT-000665-Hv for emacs-devel@gnu.org; Thu, 01 Oct 2015 19:55:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhnhS-0005m3-HH for emacs-devel@gnu.org; Thu, 01 Oct 2015 19:55:47 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhnhN-0005ld-Gp; Thu, 01 Oct 2015 19:55:41 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t91NtbjD014383 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Oct 2015 23:55:38 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t91NtY1n030340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2015 23:55:35 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t91NtYoW012352; Thu, 1 Oct 2015 23:55:34 GMT In-Reply-To: <560D6F13.3090005@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190608 Archived-At: > > Breaking backward compatibility is about the worst crime package > > maintainers could commit, in my opinion. (I know it's not shared by > > many of the others.) >=20 > This general opinion (and you're not alone holding it) is one of the > most tedious parts of the Emacs ecosystem, IME. It's not that I *love* > removing features, but being unable to do that at all makes the burden > of a maintainer harder when making changes or adding new features. Emacs is not just for its maintainers. It is above all for its users. And plenty of users, for plenty of reasons, do not use the latest & greatest version of Emacs. And yes, Emacs is exceptional in its aim to be especially easy for users to extend. Emacs is _designed_ for user extension and customization (as is Lisp, BTW). > Removing features is always a tradeoff. While no one wants to make old > users sad, if their needs would still be achievable at the cost of > workflow changes, we should be able to make that sacrifice. Whose workflow? Are you saying that you are willing to sacrifice a user's workflow & habits, so they can take advantage of the latest shiny new features you have to offer? How gracious of you! > At some point in the future (distant, in all likelihood, so this is just > a rough example), I imagine that would mean sacrificing support for > antique VC backends entirely, in favor of simpler VC implementation, or > better support of the newer backends. There's nothing stopping the > veterans from adopting modern VCSes, you know. There can be plenty of things stopping a given user from adopting your favorite modern whatever, including a VCS. Many users use tools, including Emacs that are installed organization-wide (e.g., company-wide). What percentage of Emacs users do you think build Emacs themselves for their use at work? (No, I don't have a figure in mind, but I'm pretty sure that the average core Emacs maintainer/developer is not a typical user.)