From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: please make line-move-visual nil Date: Fri, 15 May 2009 16:18:41 +0900 Message-ID: <87eiuqg7fy.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4A0C402C.7060804@slugfest.demon.co.uk> <20090514181712.GA2413@muc.de> <7C757F28-A6B2-48FB-A8AC-CF2E1728FA68@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242371574 6191 80.91.229.12 (15 May 2009 07:12:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2009 07:12:54 +0000 (UTC) Cc: Alan Mackenzie , Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 15 09:12:47 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M4rb4-0001es-1a for ged-emacs-devel@m.gmane.org; Fri, 15 May 2009 09:12:46 +0200 Original-Received: from localhost ([127.0.0.1]:59355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M4rb3-00026l-DR for ged-emacs-devel@m.gmane.org; Fri, 15 May 2009 03:12:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M4raz-00026a-Hw for emacs-devel@gnu.org; Fri, 15 May 2009 03:12:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M4rau-00026K-RM for emacs-devel@gnu.org; Fri, 15 May 2009 03:12:40 -0400 Original-Received: from [199.232.76.173] (port=53973 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M4rau-00026H-IS for emacs-devel@gnu.org; Fri, 15 May 2009 03:12:36 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:57017) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M4rau-0001Mx-22 for emacs-devel@gnu.org; Fri, 15 May 2009 03:12:36 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M4ras-0008Me-Hr for emacs-devel@gnu.org; Fri, 15 May 2009 03:12:35 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 212E21535AC; Fri, 15 May 2009 16:12:23 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AEA3C1A4583; Fri, 15 May 2009 16:18:41 +0900 (JST) In-Reply-To: <7C757F28-A6B2-48FB-A8AC-CF2E1728FA68@gmail.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110886 Archived-At: 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.