emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RCS, again: another removed functionality: undo last-checkin


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]