Re: Emacs contributions, C and Lisp

[Eric Ludlam]

On 01/10/2015 02:59 PM, Dmitry Gutov wrote:
> On 01/10/2015 10:29 PM, Richard Stallman wrote:
>
> > Getting back to completion, some tried to dismiss the idea that
> > completion can be done with less than the full AST.  The discussion
> > convinces me that it can be done with somewhat less
>
> Like Eric said, it *can* be done with a lot less, the question is
> whether we really do want to do it this way.
>
> If the plugin implements the "meat" of the completion logic (probably in
> C), Emacs could serve as a "dumb client", only forwarding completion
> queries to the plugin, and interpreting the responses.
>
> The downsides:
>
> 1. Any new feature, significant change, or a bugfix would probably have
> to touch the plugin code, which exludes contributions from a significant
> portion of the user base who would rather contribute Emacs Lisp code.

I agree with this, but

> 2. CEDET integration would basically be out of the question, while it's
> the blessed Emacs code assistance suite, which we would want to see
> developed.

I think there are fine ways to integrate tools at many different levels 
into CEDET.  Some examples include GNU Global (an external tagger), or 
javap for extracting symbol info from .jar files a source file may 
reference.  It can use exuberent ctags as a C++ parser in place of the 
built in one too (though substandard).  GCC could substitute in at any 
of those levels emitting tags in the form CEDET understands.  It could 
replace the local context parser (which is regexp based).   CEDET has a 
way to swap in alternate implementations at many different levels on a 
per language basis for this purpose.

The difference is that each custom use of gcc would be some new plugin 
implementation instead of new Emacs Lisp code interpreting some single 
output.

Eric