From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Sun, 11 Jan 2015 20:32:39 +0100 Message-ID: <87k30tqfjc.fsf@wanadoo.es> References: <83bnxuzyl4.fsf@gnu.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> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <87y4p9885b.fsf@fx.delysid.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421004797 31610 80.91.229.3 (11 Jan 2015 19:33:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 19:33:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 20:33:11 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 1YAOG6-0006fN-EO for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 20:33:10 +0100 Original-Received: from localhost ([::1]:59186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAOG5-0006N7-Qb for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 14:33:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAOFs-0006Lh-Ac for emacs-devel@gnu.org; Sun, 11 Jan 2015 14:32:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAOFp-0007Sf-4C for emacs-devel@gnu.org; Sun, 11 Jan 2015 14:32:56 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:57397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAOFo-0007SN-PW for emacs-devel@gnu.org; Sun, 11 Jan 2015 14:32:53 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YAOFm-0006Xb-Mr for emacs-devel@gnu.org; Sun, 11 Jan 2015 20:32:50 +0100 Original-Received: from 129.red-88-10-128.dynamicip.rima-tde.net ([88.10.128.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Jan 2015 20:32:50 +0100 Original-Received: from ofv by 129.red-88-10-128.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Jan 2015 20:32:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 79 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 129.red-88-10-128.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:dkh7BE53p0fLKDU+3PaRAYuxnvU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:181158 Archived-At: Mario Lang writes: > While I also think this attempt to cage data is rather absurd, I think > there is likely another misunderstanding. What Clang currently seems to > do for editor integration seems to match Richard's vision. > > While they have functionality to dump the full AST, clang-format, > clang-query, clang-rename and the completion interface don't expose a full AST at > all. Those are tools that use the Clang library. It's purpose is not to expose the innards of the compiler to other tools, but to do an specific task. The topic of this thread is to interface Emacs with GCC for building the tools in Emacs. The Clang tools are quite inflexible (actually, they are first attempts at using the Clang library; demos with some real-world applicability, if you wish.) [snip] > If GNU were to match that functionality, it would not rely on exporting > a full AST. Walking a full AST in elisp just to do completion seems > like a performance hog anyway. I don't think so. You don't need to walk the full AST for every task. And, as any other data set, the AST can be indexed in various ways. The performance hog is the generation of the AST, updating it every few seconds as the user types text. Possibly not the full AST, but only the subset that corresponds to the area being edited. IIRC Clang has support for this, dunno about GCC. > While, on the other hand, reparsing the > TU from disk via an external tool is also likely not the fastest > approach. So while performance is likely an issue with both approaches, > I just wanted to point out that AFAICS, full ASTs are not really used in > the Clang ecosystem for editor integration, they are more like a debug > tool for devs. I'm not sure what to make of your last phrase. Clang is not in the bussiness of text editors. OTOH, an editor that uses libClang for a feature might not resort to querying the AST if libClang provides higher-level APIs that do the job. > Same applies to clang-rename. You pass in a source location, and a new > name. And it parses all the involved TUs, and does the change on disk, > or serialize the changes to a sort of diff format for you to review > and apply. It is a mistake to depend on external binaries for features that can be effectively implemented on Emacs. > So the approach *they* are taking is to write external tools that do the > various refactoring jobs. Again, *they* are not on the text editor business. However, *they* are interested on showing-off their product and on tools that can work on batch mode (clang-format, clang-check) > These tools can easily be called from *any* > editor, not needing to duplicate the various refactoring features > everywhere. Uh? Do you realize that you are on emacs-devel, don't you? We don't care about how to arrange *external* projects for making them useful for *other* editors. Moreover, the tooling you propose would be a true gateway for propietary editors into using GCC for competing with Emacs. > I think this approach is rather good, and it does *not* > rely on fully exporting any AST to the various editors, because, as > already mentioned, the goal is to *not* duplicate refactoring features > in the various editing environments. > > If GNU were to match this, the work would go into tools based on GCC. > The Emacs integration should be rather simple, since we are basically > just calling a few external commands to have all the work done. See above. We don't control GCC, the hackers here are not GCC experts, we don't want to hack on GCC for every feature we want to add to Emacs, we don't want to create tools that can be seamlessly used by propietary products for competing with Emacs... the list goes on and on.