Re: please make line-move-visual nil

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Reitter writes:

 > Absolutely.  But if people don't like change, then they shouldn't be  
 > forced to upgrade if we provided decent support for older versions.

Old versions of Emacs are not very buggy.  Lack of support for old
versions simply is not an issue.  A recent survey of Emacsen conducted
at a large 4-letter financial firm I am not at liberty to name showed
over *30* different versions of Emacs/XEmacs in use, going back to
Emacs 18.55.  That in 220 responses.

What people are upset about here is that upgrades that they really do
want include backward incompatible changes that they dislike intensely
and think are stupid.

 > As you said, a new VCS will hopefully facilitate this.  I use git
 > and have evaluated Bazaar, and they both can cherry-pick bugfixes
 > from the development branch and facilitate just that.

This is a really, really bad idea, unfortunately.  This means doing
all the design review and much of the quality assurance and some
amount of the bug-fixing over again.  People who want that are already
doing it (a certain David Reitter who maintains Aquamacs comes to mind).

But the people who are complaining about *defaults for options* (!!) 
are for sure not going to find that acceptable.  What they want is the
shiny new Emacs with the particolored new features, except the stupid
ones.  In theory that could be supported by "inverse cherry-picking"
aka "spitting out the indigestible pits" (ie, reverting patches you
don't like).

But both cherry-picking and pit-spitting run into the problem that
currently Emacs workflow does not require coherent changesets.  There
is no way to assure that *this* feature is associated with *exactly
these* patches.  Making that change to workflow is going to be very
very hard, but without it the cherry-picking roll-yer-own Emacsen
strategy is highly labor intensive.

 > Projects of the size/importance of Emacs should provide a roadmap with  
 > a promise to support certain releases for x many years.

Good luck with that.  AFAIK "we support only the current version" is
explicit policy.