From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: RCS, again: another removed functionality: undo last-checkin Date: Thu, 01 Oct 2015 20:52:35 +0300 Message-ID: <83si5u8oik.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443724640 2528 80.91.229.3 (1 Oct 2015 18:37:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 18:37:20 +0000 (UTC) Cc: stephen@xemacs.org, dak@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 20:37:11 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 1Zhij7-0002nP-Ga for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 20:37:09 +0200 Original-Received: from localhost ([::1]:55268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhij6-0004eF-RR for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 14:37:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhi3V-00056B-QS for emacs-devel@gnu.org; Thu, 01 Oct 2015 13:54:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhi3U-0000ae-Mi for emacs-devel@gnu.org; Thu, 01 Oct 2015 13:54:09 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:65267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhi3Q-0000XO-0z; Thu, 01 Oct 2015 13:54:04 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NVJ00B00YYVK100@a-mtaout22.012.net.il>; Thu, 01 Oct 2015 20:52:45 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVJ00BTYYZWD590@a-mtaout22.012.net.il>; Thu, 01 Oct 2015 20:52:45 +0300 (IDT) In-reply-to: <560D6F13.3090005@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:190579 Archived-At: > Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 1 Oct 2015 20:36:19 +0300 > > On 10/01/2015 04:07 PM, Eli Zaretskii wrote: > > > No. Existing features might make no sense if (a) they didn't make > > sense when introduced (it happens!), > > You mean features that were useless or broken from the start? Yes, something like that. > > or (b) if the reason for their > > existence is no longer valid, like a program that is no longer > > available, or operation that is impossible with today's platforms, or > > so clearly unused that there's no doubt it could be still useful to > > anyone. > > ...or became irreparably broken over time. That's a pretty high standard > to consider a feature for removal. I indeed think that features should rarely be removed, only added. > When I said "doesn't make sense", I meant sense in the context of the VC > framework. Which supposedly has some internal logic, ergonomics, etc. Yes, but different VCSes have different internal logic, so something might make sense with RCS, but not with Git, or vice versa. That's the crux of the problem we are discussing, I think, so the question is whether a feature must make sense for every back-end for it to be considered as sensible. > > 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.) > > 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. We do remove features that are obsolete or no longer needed. E.g., see the 'lisp/obsolete' directory. And yes, it is harder to make changes while keeping backward compatibility. But I don't think the "solution" of breaking backward compatibility is the main or even desirable one. It should be the last resort, unless we are sure the feature is of no use. > > It makes veteran users of a package feel like > > second-class citizens whose needs and workflows can be disregarded all > > too easily. > > 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. For some features, a change of the workflow could be justified, for others, those which are too popular and ubiquitous with their users, it can't. I disagree that this sacrifice is always possible, let alone desirable. Especially when the change in the workflow boils down to "do it from outside Emacs". > 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. I think there's a better alternative: start a new front end, which will only support a subset of back-ends. Then the elders can peacefully continue using the old front-end, which will more or less stop being developed, only maintained whenever some of the infrastructure changes absolutely require that. > There's nothing stopping the veterans from adopting modern VCSes, > you know. Muscle memory is what stopping them. It's a powerful thing.