|
From: | Dmitry Gutov |
Subject: | Re: RCS, again: another removed functionality: undo last-checkin |
Date: | Thu, 1 Oct 2015 22:29:30 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 |
On 10/01/2015 08:52 PM, Eli Zaretskii wrote:
I indeed think that features should rarely be removed, only added.
Then you must be prepared that at certain point the cost of improving Emacs will be too much for anyone to do anything of significance to it.
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.
It may be decided on a case-by-case basis, but the question is rather whether it *could* be decided at all. The exact criterion, "make sense for at least a half of all backends", or "make sense in at least one of the modern backends", is up for discussion.
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".
I still think it's just fine for rare operations. Even those performed regularly, but at long-ish intervals.
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.
It's an option indeed, though one that requires a larger investment of time (which we don't have a lot of to spare). And what if we make some unfortunate decision WRT to features when creating the second front-end, too? Wait a few years and create a third one?
It also assumes that the set of backend commands can be static without incurring any cost. Whereas the most recent overhaul by ESR featured some beneficial changes in it.
Muscle memory is what stopping them. It's a powerful thing.
It's easier to change than a big codebase full of features one is absolutely not allowed to break.
[Prev in Thread] | Current Thread | [Next in Thread] |