From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mario Lang Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Sun, 11 Jan 2015 23:25:52 +0100 Message-ID: <87y4p9ymxb.fsf@fx.delysid.org> References: <83bnxuzyl4.fsf@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> <87k30tqfjc.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1421015169 11232 80.91.229.3 (11 Jan 2015 22:26:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 22:26:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 23:26:03 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 1YAQxP-0007HT-A4 for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 23:26:03 +0100 Original-Received: from localhost ([::1]:59574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAQxN-00023k-SG for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 17:26:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAQxJ-00023d-Pm for emacs-devel@gnu.org; Sun, 11 Jan 2015 17:25:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAQxG-0007zX-JM for emacs-devel@gnu.org; Sun, 11 Jan 2015 17:25:57 -0500 Original-Received: from familiekainz.at ([91.121.101.210]:57140 helo=ks354034.kimsufi.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAQxG-0007zS-A0 for emacs-devel@gnu.org; Sun, 11 Jan 2015 17:25:54 -0500 Original-Received: from fx.delysid.org (chello080109200215.3.sc-graz.chello.at [80.109.200.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ks354034.kimsufi.com (Postfix) with ESMTPSA id 4070ABF649 for ; Sun, 11 Jan 2015 23:25:53 +0100 (CET) Original-Received: from mlang by fx.delysid.org with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YAQxE-00026L-R5 for emacs-devel@gnu.org; Sun, 11 Jan 2015 23:25:52 +0100 In-Reply-To: <87k30tqfjc.fsf@wanadoo.es> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Sun, 11 Jan 2015 20:32:39 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 91.121.101.210 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:181162 Archived-At: =C3=93scar Fuentes writes: > 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 fu= ll 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.) My point was exactly that. A solution to the aledged problem of not wanting to leak a full AST is to have specific tools do specific jobs. Yes, I know these tools would be a part of GCC. However, since the discussion seems to involve overall GNU strategics, I think it isn't wrong at all to consider pushing the work to another project, if that solves a strategic problem. >> 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. I can certainly see that some people would want to *have* the AST in Lisp, to be able to do clever hacks on top of that. I am not questioning the potential usefulness of that. All I wanted to point out was, that there is a solution to the AST export problem. We might not be able to do clever on-the-fly hacks, but with tools like gcc-query and gcc-rename we could at least get much further then we currently are. >> 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. Clang is not a text editor, but with Clang tooling, it definitley tries to offer IDE integration. >> 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. True. However, if we can't export the AST for some reason, external tools would be a useful alternative approach. >> 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) That's not quite true, if you also consider clang-rename and clang-query. >> 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 am deeply sorry for having proposed a reusable solution. What was I thinking. EOT. --=20 CYa, =E2=A1=8D=E2=A0=81=E2=A0=97=E2=A0=8A=E2=A0=95