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: Emacs contributions, C and Lisp Date: Wed, 12 Mar 2014 15:51:23 +0900 Message-ID: <87zjkvnc44.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> <87d2i9ee8t.fsf@engster.org> <874n3ke1qn.fsf@engster.org> <87sir336qn.fsf@fencepost.gnu.org> <20140301215057.GA19461@thyrsus.com> <87fvn1y0vx.fsf@fencepost.gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> <87mwgwez7o.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1394607109 15075 80.91.229.3 (12 Mar 2014 06:51:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2014 06:51:49 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org, Stefan Monnier , Richard Stallman To: Jambunathan K Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 12 07:51:56 2014 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 1WNd19-0002ma-CV for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2014 07:51:55 +0100 Original-Received: from localhost ([::1]:58974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNd19-00009Z-2z for ged-emacs-devel@m.gmane.org; Wed, 12 Mar 2014 02:51:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNd0y-00007s-NZ for emacs-devel@gnu.org; Wed, 12 Mar 2014 02:51:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNd0r-0005zr-Dc for emacs-devel@gnu.org; Wed, 12 Mar 2014 02:51:44 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:56416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNd0h-0005xn-8Z; Wed, 12 Mar 2014 02:51:27 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2783B970979; Wed, 12 Mar 2014 15:51:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 197DD1A28DC; Wed, 12 Mar 2014 15:51:24 +0900 (JST) In-Reply-To: <87mwgwez7o.fsf@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:170287 Archived-At: Jambunathan K writes: > Is it about: > > 1. Making new features available within Emacs? > > - completion Yes. > - refactoring Different posters have different views on that. > 2. Making new features through *a specific* means. > > - llvm only > - gcc only I don't think anybody advocates anything-only at this point. Some posters clearly believe LLVM *first* is a good strategy, because it provides a very detailed description of the semantics of identifiers out of the box. However, Richard has declared LLVM may not be used for development of these features[1], so this issue is moot. David's point about LLVM support being implicitly LLVM-only is about the pragmatic outcome of any implementation using LLVM: to some extent it is very likely to detect LLVM-only C/C++ extensions and provide appropriate "advice" to Emacs completion, but it would be rather difficult to serve GCC-only extensions in the same way. (Did I get that right this time, David?) If that is "first", then (at least for a while) the effect will be LLVM-only in this sense.[2] > 3. Improving and stregthening the overall ecosystem. Always, for any GNU project. (But beware, Richard deprecates terms like "ecosystem" and "ecology", I forget exactly why. Something about GNU not being an emergent outcome of random evolution, but rather being designed and organized specifically to support software freedom, IIRC.) > Hyper-linking to other Free-software out there. Dunno what you mean by that. > - co-opeation with GCC Richard wants that, both in this case and as a general matter of greater unity within GNU as a whole. I'm not sure if it's realistic to expect much direct cooperation in this case, the skill sets are rather different. > - co-opeation with LLVM Not as a project, that's clearly out because of the licensing. Importing bits of LLVM code into GNU projects, yes, but not the other way around. > If the focus of this thread is (1), it is better to invite CEDET > developers and ask for their inputs. They're already here, and have been providing their input all along. The consensus of CEDET supporters seems to be that LLVM tools might potentially be somewhat more accurate, but that existing CEDET features plus some additional heuristics should give excellent results. > Shouldn't (1) merit equal attention? I would say that's David Kastrup's point (except that he would say that's really the only thing to focus on, use of GCC or CEDET is just a question of of the inclination of the developers who actually do the work and the available features). I suspect David K would also advocate sticking specifically to "completion" as the feature in question. Trying to generalize the set of features to be supported leads pretty quickly to relatively abstract discussion of the advantages of LLVM's architecture for building code analysis toolkits (whether in the compiler suite or in Emacs Lisp), which doesn't help to get people to start working on the features. Footnotes: [1] Of course to the extent that LLVM provides the same UI as GCC, users cannot be prevented for using LLVM instead of GCC. But no LLVM- specific options or I/O formats may be supported. [2] Don't anybody bother objecting that the common subset of syntax would serve both LLVM and GCC users. Neither David nor Richard objects to that, but they do not consider it a mitigating circumstance.