[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Eric Ludlam
Subject: Re: Emacs contributions, C and Lisp
Date: Sat, 10 Jan 2015 18:40:00 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]