From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Wed, 07 Oct 2015 20:11:28 +0200 Message-ID: <87oaga7dm7.fsf@fencepost.gnu.org> References: <87lhbmkrle.fsf@fencepost.gnu.org> <87si5r22qh.fsf@fencepost.gnu.org> <5612CEA6.3010809@yandex.ru> <87egh95cze.fsf@gmail.com> <5612D36B.1030906@yandex.ru> <87a8rx5awg.fsf@gmail.com> <87a8rvu0ij.fsf@red-bean.com> <87wpuyq5e5.fsf@russet.org.uk> <22037.21947.285752.82115@turnbull.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444241509 32335 80.91.229.3 (7 Oct 2015 18:11:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 18:11:49 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 07 20:11:48 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 1ZjtBq-0002ev-Ct for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 20:11:46 +0200 Original-Received: from localhost ([::1]:58946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjtBp-0000tP-ID for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 14:11:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjtBc-0000tC-5w for emacs-devel@gnu.org; Wed, 07 Oct 2015 14:11:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjtBb-0003Gy-0z for emacs-devel@gnu.org; Wed, 07 Oct 2015 14:11:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjtBa-0003Gu-U9; Wed, 07 Oct 2015 14:11:30 -0400 Original-Received: from localhost ([127.0.0.1]:54863 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZjtBZ-00044I-9R; Wed, 07 Oct 2015 14:11:29 -0400 Original-Received: by lola (Postfix, from userid 1000) id BF3D6E0F7D; Wed, 7 Oct 2015 20:11:28 +0200 (CEST) In-Reply-To: <22037.21947.285752.82115@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Thu, 8 Oct 2015 02:26:19 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:191054 Archived-At: "Stephen J. Turnbull" writes: > John Wiegley writes: > > > I'm beginning to think GNU Emacs will need someone who also cares > > about the freedom argument first, and the technical needs second, > > because I'm very much concerned I would chomping at the bit to move > > forward, and unable to for reasons I don't necessarily agree with. > > I wouldn't worry about that if I were you. The principle itself > bothers me a heck of a lot more than the exercise of it does. > > In the twenty years I've been following Emacs development, I can > remember only four occasions where Richard has deliberately sacrificed > significant improvements to Emacs in the name of promoting either > software freedom or the GNU Project: TRAMP, Bazaar, DSOs, and now use > of the AST exported by LLVM. > > Of course, the TRAMP mistake has long since been corrected, and the > Bazaar fiasco is a thing of the past. The no-DSO policy has been > rescinded recently, and work is actively proceeding on adding that > feature. LLVM? "This, too, will pass." To put more precision to it: usually the point of time where the strategy changes is when it has become pointless. Since LLVM already outputs annotated syntax trees, blocking GCC from that kind of interoperation is not going to achieve a useful purpose for the GNU project at the current point of time. So I don't expect that restriction to stick around for all that much longer in the current form: after all, we don't have anything to gain from people putting LLVM into their applications rather than GCC even if we had preferred such applications to fall under the GPL because of tight integration with GCC. -- David Kastrup