Re: Emacs contributions, C and Lisp

[Mario Lang]

Óscar Fuentes <address@hidden> writes:

> 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.)

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.

-- 
CYa,
  ⡍⠁⠗⠊⠕