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 19:49:36 +0100 Message-ID: <87y4p9885b.fsf@fx.delysid.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> 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 1421002205 20362 80.91.229.3 (11 Jan 2015 18:50:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 18:50:05 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 11 19:49:59 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 1YANaI-0005HQ-G8 for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 19:49:58 +0100 Original-Received: from localhost ([::1]:59113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YANaH-0006MP-Iu for ged-emacs-devel@m.gmane.org; Sun, 11 Jan 2015 13:49:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YANa4-0006MJ-Vf for emacs-devel@gnu.org; Sun, 11 Jan 2015 13:49:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YANa1-0002qo-OX for emacs-devel@gnu.org; Sun, 11 Jan 2015 13:49:44 -0500 Original-Received: from familiekainz.at ([91.121.101.210]:56748 helo=ks354034.kimsufi.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YANa1-0002qd-G4 for emacs-devel@gnu.org; Sun, 11 Jan 2015 13:49:41 -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 E173EBF649 for ; Sun, 11 Jan 2015 19:49:38 +0100 (CET) Original-Received: from mlang by fx.delysid.org with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YANZx-0004R8-6i for emacs-devel@gnu.org; Sun, 11 Jan 2015 19:49:37 +0100 In-Reply-To: (Stefan Monnier's message of "Mon, 05 Jan 2015 22:24:05 -0500") 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:181156 Archived-At: 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. 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. 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. 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. So the approach *they* are taking is to write external tools that do the various refactoring jobs. 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. The Emacs integration should be rather simple, since we are basically just calling a few external commands to have all the work done. --=20 CYa, =E2=A1=8D=E2=A0=81=E2=A0=97=E2=A0=8A=E2=A0=95