Is it feasible to extract the code assist/completion part from Eclipse and use it in an other editor?

Question

I often hear how good the code completion, coding assist features of Eclipse are compared to other editors which raises the question if these parts could be separated from the Eclipse code base.

If this part is separated with an API through which it can be told things it needs to know (where are the files of the project, what are the include paths, etc.) then it can return the necessary information (help for a symbol at the cursor, possible completions, etc.) and any editor (emacs, vim, etc.) can use it.

Why is it not done already? Are these code assist parts tied too tightly to Eclipse internals and they can't be sepaarated easily? Could someone who knows about the internal workings of Eclipe shed some light on this?

Edit: Here's a working setup with SharpDevelop for C#, emacs is the UI and the info comes from the SharpDevelop module. See the screenshot on this page. Eclipse's completion support could support emacs and other editors similarly.

Answer 1

The eclim project tries to solve this problem by interfacing directly with eclipse. Thus at least an headless running eclipse is required. While eclim's focus is afaik the vim integration, there also exist plugins for other editors (emacs, textmate, etc). The communication between eclim and an editor happens through a server interface.

Maybe not exactly what you where looking after, but imho worth a look:

http://www.eclim.org/

Answer 2

The content assist uses an internal model of the Java projects - without this model the content assist cannot work (that effectively).

I am not sure, how tightly is integrated to Eclipse internals, but I do know that it uses the Eclipse Resources API (file system handling) and other features such as Eclipse extensions (new completion providers can be added without modifying the code).

Alltogether, I believe to port this completion engine to other editors the mentioned editors would lose their (in some case relative) simplicity to Eclipse, thus it might not provide the smaller footprint of the mentioned editors - so I don't think, it is feasible to provide such engines effectively for other editors.