Re: Emacs contributions, C and Lisp

[Mario Lang <mlang@delysid.org>]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

-- 
CYa,
  ⡍⠁⠗⠊⠕