Re: Emacs learning curve

["Eric M. Ludlam" <eric@siege-engine.com>]

On 08/02/2010 03:53 PM, joakim@verona.se wrote:
> Lennart Borgman<lennart.borgman@gmail.com>  writes:
>
>> On Mon, Aug 2, 2010 at 8:39 PM, Tom<levelhalom@gmail.com>  wrote:
>>>
>>> And why not add these by simply reusing the work of others?
>>>
>>> The most requested and popular features are code
>>> completion, refactoring and such. I know CEDET can do some of
>>> these, but I wonder if Emacs should harness the effort put into
>>> these areas by other development teams.
>>>
>>> Take a look at the screenshots IdeBridge for example:
>>>
>>> http://www.emacswiki.org/emacs/IdeBridge>
>>>
>>> It uses SharpDevelop libraries to provide completion. I know a
>>> pure elisp solution would be the best, but given the plethora of
>>> languages it's not a realistic goal to provide a comprehensive
>>> Elisp backend solution for everything due to limited developer
>>> resources.
>>>
>>> The best approach may be to provide a standard code
>>> completion (refactoring, documentation lookup, etc.) frontend in
>>> Emacs into which any backend implementation can be
>>> plugged. People would write bridge code like in the above example
>>> to handle communication between the frontend and the selected
>>> backend. There are no licensing issues, because it can work
>>> with process communication.
>>
>>
>> I think that CEDET already makes this possible, but Eric can surely
>> give a better answer. (Maybe this should be pointed out very clearly
>> in Emacs doc, at least as a goal?)
>
> Just to reiterate, (Eric will surely put it better):
> - Cedet is as the name implies "a Collection of Emacs Development Tools"
> - One tool is Semantic, which basically is a collection of interfaces
> and different implementations of parsers for various languages
> - It is possible to implement the semantic interfaces on various
> different backends, several such implementations are included in Emacs.
>
> I worked on a couple of such implementations, and while its not always
> super obvious how to do it, I think anyone with a genuine interest in
> implementing a new backend to Semantic can do it. In fact, not using the
> Cedet interfaces is what would be a waste, its the best shot Emacs has
> at implementing these modern ide facilities.

As is suggested above, CEDET is a a bunch of interfaces with default 
back-ends and front ends.  It is similar in nature to GUD or the VC 
stuff, but instead uses different mechanisms to create the abstraction.

A large portion of the miscellaneous tools in CEDET use EIEIO to create 
a series of base classes that define the interface or API that some user 
interface interacts with.  Some examples are:

EDE - This defines some basic concepts of what a project and target are. 
  It then implements project styles for Automake, Make, Emacs, Linux, 
and some others.  On top of these classes is global-ede-mode.  This 
defines a menu and some misc keybindings for compilation or whatever.

In the context of some external tool like SharpDevelop, Visual Studio, 
Eclipse or whatever, if it is possible to read those project files EDE 
can wrap it and the implementation can dispatch back out to that tool to 
do the project management work.  Someone who then learns how to work in 
one kind of project in Emacs (via keybindings or what-not) will know how 
to work in another project even if the back-end is totally different.

Semantic then uses the EDE interfaces to provide project level 
configuration of what files to search or what CPP macros exist.

SemanticDB - The databases used by Semantic to track tag info which is 
used for completion is also based on EIEIO classes.  The default just 
saves stuff to disk, but other back-ends, such as the Emacs backend uses 
Emacs commands to lookup symbols, or the GNU Global backend can query a 
GNU Global database.

The Semantic tools also use mode-local to create an interface boundary. 
  In this case, on a per-mode basis.  Thus the C++ support use the 
parser generator in Semantic to parse the code in a buffer and save off 
the tags.  External parsers can be installed used instead, such as the 
exuberent ctags parser, so on a per-mode basis, you can configure and 
use different backends.

The completion engine is the same.  If there is an alternate 
implementation for creating a list of possible completions for a 
particular mode, you can override the right function to provide the 
output.  Any tool that uses Semantic's smart completion engine would 
then automatically start using the new external tool (such as 
SharpDevelop) instead.

Not yet a part of Emacs, the COGRE UML tool uses the Semantic back end, 
mode-local override features, and EIEIO to generate code from high-level 
concepts such as class diagrams.  COGRE uses EIEIO, and any kind of 
connected graph could be created besides the UML implementation.

I hope this helps answer questions.  I do think that the original 
poster's desire for a place to put a back-end already exists in the 
CEDET infrastructure, and if it doesn't do it perfectly for some case, 
we can certainly tweak the API if needed.

Eric