Re: Emacs contributions, C and Lisp

[David Kastrup]

Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > In a modern IDE, you can complete anything -- struct members or
>   > object member variables/functions, type names, etc., etc., and you
>   > need what are essentially compiler data structures to get that stuff,
>   > and you need the AST to understand the context in which you're
>   > requesting the completion.
>
> I am not convinced this requires the entire AST.
> I think it could be done with a lot less.
>
> It certainly can be done with less.  For instance, if the code says
>
>   foo.x + bar.y
>
> or
>
>   foo.x - bar.y
>
> it makes no difference for completion what that operator is.

In C++, I am afraid you are wrong.  It depends on what types operator+
and operator- may be defined for.  If you define operator+ on a
half-group, you won't generally have operator- available.

Operator overloading is a reality in C++.  For example, << and >> are
seriously overloaded for the <iostream> standard library.

> Clearly there is information from the AST that need not be included in
> order to fully support completion.

Probably.  However, if you don't want to cause major pain when
reevaluating your requirements, it is important that you don't need to
change/recompile several _differently_ maintained and versioned pieces
of software in lockstep to adapt to changed requirements.  If you can
shake plugins interfacing to Elisp out from GCC without having them tied
to a particular version of GCC basically on the fly, you don't need to
have the whole AST available in a physical form.

But the plugin interface then needs to be general and convenient enough
to get any aspect of it on-demand.  And with regard to enabling
undesirable uses of it, I don't see that this buys us significant
savings over a non-Emacs specific AST dump.

> I think you propose "entire AST" because it is conceptually satisfying
> to you, not because all the data in the AST are necessary.
>
> What data ARE necessary?

It depends on the level of sophistication in the editing modes.  If we
want the editing modes to be able to evolve without being constrained to
the GCC release cycles, we need either rather generically useful data,
or generically useful GCC extension interfaces.

Keeping all of our babies while throwing out all of the bath water for
evolving notions of babies and bathwater is not likely to work well.

I don't really see that we have much of a chance not to be hobbling us
ourselves more in the process than currently hypothetical leeches.

-- 
David Kastrup