Re: Emacs contributions, C and Lisp

[Óscar Fuentes]

Mario Lang <address@hidden> 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.