Every once in a while, I become envious of some features that aren’t present in Emacs - semantic auto-completion, error highlighting that works well, or something else - and try out a new editor. Recently, this was Eclipse, since I was doing some Java programming and most Java programmers I know use it. It has very good code analysis and navigation, which JDEE used to provide to a degree, but JDEE was much more buggy and less usable.
The thing that keeps me coming back to Emacs is it’s extensibility and Emacs has a plugin infrastructure, so I was hoping that this may give me the ability to patch up the things I didn’t like about it - notably, I found the actual editing of text to be horrible, although this was somewhat mitigated with the EmacsPlus plugin. To see how the process of developing a plugin was, I decided to write a very small one, located at http://github.com/nflath/eclipse-hungry-delete/.
This plugin implements hungry-delete functionality in Eclipse. It is a fairly simple concept; if you are deleting whitespace, delete all whitespace in the direction you are deleting. The plugin for this in Emacs is less than a hundred lines of very obvious code long, so it’s not something that I thought would take much time to reimplement in Eclipse. In the end, it took me a lot longer than I thought, and it ended up being much more unpleasant than writing an Emacs plugin.
Finding documentation was an enormous pain, especially when used to emacs’ apropos and describe-key. For those that don’t know, describe-key will tell you exactly what command is executed when you give a key sequence; this is one way to find out one way to call commands. Apropos lets you search through every function defined in Emacs. However, it took a while to find information on any more functions than were needed by whichever example was being implemented in a tutorial; the commands are split up into hundreds of jar files, so there is no really good way to determine what commands are possible or how to do them. Additionally, if you do manage to find a class you wanted, it usually didn’t tell you what jar it was in, and so you had to experiment based on the jar names. Fun. I ended up having to download another plugin and examine it’s source to see how it modified the current document, as I couldn’t find documentation online.
Eclipse plugins being written in Java also means that they tend to be much more verbose than Emacs plugins, which made it a lot less fun to write. The way the plugin was structured also meant I had to split the code among four files, and it ended up being over twice as long. Once I had written the commands, I still had to actually define them as commands, a step Emacs doesn’t require. The plugin editor Emacs had made this beter than just editing the XML, but it was still a laborious process, and I didn’t find a way to rebind the Delete key to do this, having to settle for Ctrl-D.
All in all, the process was pretty painful, and I didn’t even have to interact with anything but the currently opened file. I looked at what would be required for some other things that I thought would be nice - an Ido-like file opener and having a shell in the console - and didn’t find much information on them. Eclipse as such fails in the extensibility department, and some of the functionality I have in Emacs is more important than the benefits Eclipse gives me. Until I can fix Eclipse’s problems more easily, I’ll be using Emacs as my primary Java editor.