From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Sun, 11 Jan 2015 21:13:54 +0100 Message-ID: <87387hrs71.fsf@engster.org> 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 1421007267 8675 80.91.229.3 (11 Jan 2015 20:14:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 20:14:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mario Lang Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 21:14:22 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 1YAOtv-0007fD-IA for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 21:14:19 +0100 Original-Received: from localhost ([::1]:59253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAOtu-0008Fn-Sx for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 15:14:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAOth-0008Er-Fj for emacs-devel@gnu.org; Sun, 11 Jan 2015 15:14:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAOtd-0001z2-Cf for emacs-devel@gnu.org; Sun, 11 Jan 2015 15:14:05 -0500 Original-Received: from randomsample.de ([5.45.97.173]:42024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAOtd-0001yw-0q for emacs-devel@gnu.org; Sun, 11 Jan 2015 15:14:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=75wxE0IRAa0d7AtXtP/3xxE4keGj+XJRTgRHFtoxRLg=; b=FvJj7fQ4B9n9L3nUQsAOrDpXLeaFBV0VANsY9VQEiRzjx06VVB65Ttl8DR918q16686tVLrzsdloLQK+iQ3P+7tnpzMCQXEiP66DKR4/1wcj75iJ/l7xtmvwUJBH2/tx; Original-Received: from ip4d154cb9.dynamic.kabel-deutschland.de ([77.21.76.185] helo=spaten) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YAOtb-0003rJ-KG; Sun, 11 Jan 2015 21:14:00 +0100 In-Reply-To: <87y4p9885b.fsf@fx.delysid.org> (Mario Lang's message of "Sun, 11 Jan 2015 19:49:36 +0100") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:181160 Archived-At: Mario Lang writes: > Stefan Monnier writes: > >>>> > To figure out just what Emacs needs, that's the task I am talking >>>> > about. >>>> If you want to support things like completions, refactoring, symbol >>>> searches, etc., we need full access to the AST from inside Emacs. >>> With all due respect, it is so important to avoid the full AST >>> that I'm not going to give up on it just because someone claims >>> that is necessary. >> >> Give up on what, exactly? >> >> Richard, this is absurd! >> I'm convinced there is a misunderstanding. > > 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. The idea behind the Clang tools is that they parse > the translation units on their own, and do manipulations on the data > internally. You pass parameters to these tools, like a position in a > file you want to see completions for, or a range of locations to > reformat, or a matcher expression to search for particular AST > constructs. There is one important point that needs to be mentioned: all those tools, as well as the clang binary itself, are not really "external". They all simply call functions from libclang. You probably know this, but this has already confused people here. Therefore, to do what libclang does, you would have to implement all that functionality inside GCC. I don't doubt that it is possible - it's just software, after all. However, you would need experienced GCC hackers to do that, since you need to hook yourself deep into the parser to do what libclang does. AFAIK, this is not possible with a mere GCC plugin. Unfortunately, GCC hackers are a rare breed. I'm not one of them, and I don't plan to become one. So my goal is to get GCCs internal data into a hacking-friendly environment, which essentially means "out of GCC". My understanding is that due to clang's modular architecture and because it is implemented as a library, it is much easier to hook yourself into it than it is in GCC. For instance, implementing something like completions inside GCC is not trivial at all. There was actually a patch which tried to implement this (search in their mailing list for 'gccsense'). It was realized by introducing a "phantom token" into the lexer, and when the parser would reach that token, it would spill out the possible completions based on the current AST. This patch was rejected because it is arguably a hack and would be very hard to maintain. I actually pointed Richard to this patch over two years ago; he wanted to investigate, and I never heard back. > 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. Walking the full AST in Elisp is out of the question, yes. Some stuff must be done inside the plugin. For instance, matching certain expressions in the AST could be done there. And whatever Emacs does must be done lazily, meaning only looking at those parts of the AST that are currently in scope; and with heavy caching, of course. Fortunately, much of that infrastructure is already present in CEDET. I would also envision external tools. For instance, CEDET already relies on GNU Global for finding references. One could extend GNU Global to use GCC's AST instead of parsing the files itself, and introduce new queries specific to C++. > So the approach *they* are taking is to write external tools that do the > various refactoring jobs. Again: not "really" external. It's all libclang. > These tools can easily be called from *any* editor, not needing to > duplicate the various refactoring features everywhere. 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. But those tools would need the AST! This is precisely what Richard does not want. So the only solution is to do it inside GCC. I'm not opposed to that approach at all, but it's not like this is a new idea. GCC is very hard to hack on, and my guess is that there's simply no manpower to implement this. -David