Bug 69516 - [EditorMgmt] Ability to plug in alternative editors, for example GVIM or emacs
Summary: [EditorMgmt] Ability to plug in alternative editors, for example GVIM or emacs
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P5 enhancement with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2004-07-07 15:22 EDT by Justin Wells CLA
Modified: 2019-09-06 16:17 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Wells CLA 2004-07-07 15:22:37 EDT
I raised this point at a JavaOne eclipse BOF but we never got a chance to talk 
about it. Here is the idea in full:

You should be able to plug in an alternative editor rather than using the 
editor that comes with eclipse. For example, you should be able to write a 
plugin that would wrap around GVIM to provide VI functionality in eclipse. Note 
that I am not talking about "VI key bindings", which would not add any 
functionality to eclipse, but rather I am talking about using GVIM as an OLE 
object within Eclipse via a plugin--gaining access to the full power of the 
GVIM (or other) software.

For reference a competing product, the Intellij/IDEA IDE, has a plugin that 
wraps around GVIM as an OLE object. It renders the text within the Intellij 
window so that all of the smart IDE features still work (syntax highlighting, 
hyper navigation, mouse-overs, etc.) but the text buffer itself is actually 
managed by vim. It is not just a set of keybindings that are VI like, it 
actually wraps VIM as an OLE object. The plugin forwards the key strokes to the 
VIM editor, and VIM has support for this kind of use. The feature should not be 
VIM specific but should enable plugin writers to create plugins for any editor 
with API bindings.

That all said I do have to wonder why in this day in age anyone would ever set 
out to write a new editor. There are a lot of mature, reliable, well known, and 
widely used editors out there that are all better than the paltry homegrown and 
necessarily immature editor provided in Eclipse: gvim, emacs, ultraedit, 
textpad, etc., etc., etc. Allowing eclipse to integrate with the users 
default/preferred editor not only buys you a better editor, it provides for 
seamless integration with the rest of the platform, and saves you the trouble 
of having to write one!

Catching up with the functionality provided by VIM or EMACS or whatnot is a 
herculean task that will only serve to distract the eclipse team from working 
on its core values: the smarts about navigating, indexing, cross-referencing, 
refactoring, debugging, and generally building software.
Comment 1 Michael Van Meekeren CLA 2006-04-21 13:18:48 EDT
Moving Dougs bugs
Comment 2 Gavin Gilmour CLA 2008-07-19 09:42:49 EDT
Expressing my interest, though I fear this will never happen. :(
Comment 3 Boris Bokowski CLA 2008-07-19 11:46:28 EDT
Well, there is always the possibility to contribute a patch.  Feel free to contact me if you need additional details.

http://wiki.eclipse.org/Platform_UI/How_to_Contribute
Comment 4 Boris Bokowski CLA 2009-11-17 13:05:42 EST
Remy is now responsible for watching the [EditorMgmt] component area.
Comment 5 Eclipse Webmaster CLA 2019-09-06 16:17:55 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.