[Top][All Lists]

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

Re: Emacs learning curve

From: Eric M. Ludlam
Subject: Re: Emacs learning curve
Date: Tue, 03 Aug 2010 18:07:03 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

On 08/02/2010 03:53 PM, address@hidden wrote:
Lennart Borgman<address@hidden>  writes:

On Mon, Aug 2, 2010 at 8:39 PM, Tom<address@hidden>  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:


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

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.


reply via email to

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