I’ve blogged before about the difficulties I’ve had in finding a solid, general-purpose text editor for my system. I looked into VIM for Windows, E, SciTi and many more before finally settling on jEdit. It’s a really good editor, if a bit rough around the edges. A lot of people (myself included) would put it on par with TextMate in terms of features, and superior to it in some ways thanks to its cross-platform nature.

As a separate application from my IDE, jEdit performs superbly, but although this solves the problem of editing arbitrary files from file explorer, it still leaves open the problem of editing arbitrary file types within Eclipse. What I had been doing is using jEdit as an external editor, opening it up any time I needed to open a weird file type within Eclipse. This works fairly well, but it’s heavy on memory, not integrated with tools like Mylyn (as if there were any tools like Mylyn) and it’s just annoying, dealing with a separate app like that.

What I really want is some sort of embedded jEdit editor canvas within a normal Eclipse editor part. One would think this would be very possible, given SWT_AWT and its capabilities. In fact, I was just about to crack open the jEdit source to see if I could roll something myself when an eternal axiom sprang to mind: Google is your friend. Actually in this case, I used Eclipse-Plugins.info (which IMHO is still the best Eclipse plugins site, despite lacking an active administrator) and did a quick search for any plugins mentioning the word “jedit”. A few minutes later, I was perusing the page for the little-known Color Editor plugin.

Color Editor is basically a simple Eclipse editor which will open any file for you. It’s not much more sophisticated than the standard Text Editor which is the default for unknown file types. However, what it *does* do is parse jEdit’s mode.xml files, providing semi-advanced syntax highlighting for over 150 file types. Granted, it doesn’t have all of jEdit’s nice editing features or plugins like SuperAbrevs, but if I need that I’ll open up jEdit itself. For most of what I do, quick-and-dirty syntax highlighting is all I need.

The problems with this plugin are mainly caused by the fact that it’s quite old and hasn’t really been updated recently. It still defaults to the old-style jEdit colors, which are ugly as sin. Also, it doesn’t support as granular syntax highlighting as the current version of jEdit (only 2 comment types, 2 literals, etc). It doesn’t support easy adding of modes (you have to repackage the plugin JAR file), nor does it allow you to simply point it to the same mode catalog used by jEdit itself (which would simplify management of editor modes). Despite all of that, it’s still a really nice idea.

The plugin works not by embedding a jEdit editor canvas using SWT_AWT, but by just using the standard Eclipse syntax highlighting techniques coupled with the jEdit mode files. The downside to this approach is the need to write a whole bunch of mode parser code which is effectively already done within jEdit. Also, odd bugs can leak in around the edges, since the editor is effectively reverse-engineering the jEdit editor part. However, the approach does have a very unexpected (and pleasant) silver lining: fonts look good.

I’ve had tons of problems with jEdit’s font rendering on Windows, mainly due to the fact that Swing’s font renderer doesn’t seem to be as sophisticated as Vista’s (or at least, less capable of dealing with monospaced fonts). But since Color Editor uses native font rendering, the text looks 100% native:

jEdit

Eclipse Color Editor

I assume you can see the difference. So, fonts look great, but if you examine the body of the method in the file a bit more, you’ll see examples of those odd bugs I was talking about. For some reason, Color Editor thinks that the suite variable, as well as the BaseTests, DBTests, SchemaTests and TypeTests classes are all methods, rather than local variables and classes. This is annoying, but it’s not the end of the world. Granted, I haven’t been using this tool for all that long, but I’m guessing that instances like this are fairly rare, and not cause for immediate alarm. You’ll also notice some evidence of the lessened flexibility in the syntax highlighting engine (fewer types of comments in this case) in the way the javadoc and single-line comments are colorized differently.

All you have to do is stick the JAR in your eclipse/plugins directory and start Eclipse with the -clean option (usually unnecessary, but just to be safe). Color Editor will automatically be registered as the default editor for unknown file types. If you want to change the default colors (as well you should), you can find the preference under Coloring Editor -> Colors (no idea why the conjugation difference between the editor name and the preference pane). It’s a bit clumsy to try and set all of the colors to a predefined theme (I made mine look like the current jEdit defaults), but it’s all possible.

Hopefully you’ll find this a useful tool in editing those random shell scripts and who-knows-what-else which got included in the project, but for which Eclipse doesn’t have a separate plugin.

Hmm, looks interesting. I couldn’t find screenshots though, are there any available?

What I’m really looking for at this point is the same sorts of features provided by jEdit, and I mean more than just universal syntax highlighting. SuperAbrevs is like a divine gift to the universe as a whole (I love Tab completion), and jEdit’s syntax highlighting *is* more advanced than Color Editor is able to replicate.

BTW, I’m jEdit’s biggest fan (particularly its regex search and replace), but it seems a little clunky these days for most of my text editing tasks.

Todd ChamberyThursday, November 1, 2007 at 5:28 am

Ah, the chambery.subfire.org screenshot finally loaded for me. It’s an interesting idea actually, implementing a text-editor as a stand-alone Eclipse app, but I’m not sure I’d want to load anything that heavy-weight for simple text editing.

As a plugin though, it seems a lot more interesting. I’m a little leery about using a C++ based coloring library, but I’d imagine it’d be nice and fast. I’ll have to put this on my “to check” list. Can you add syntaxes (like Color Editor allows adding of jEdit modes)? Also, does it have more advanced features like auto-insertion of brackets in recognized languages, etc.. ?

Post a Comment

Comments are automatically formatted. Markup are either
stripped or will cause large blocks of text to be eaten, depending
on the phase of the moon. Code snippets should be wrapped in
<pre>...</pre> tags. Indentation within
pre tags will be preserved, and most instances of
"<" and ">" will work without a problem.

Daniel Spiewak is a software developer based out of Wisconsin, USA.
Over the years, he has worked with Java, Scala, Ruby, C/C++, ML,
Clojure and several experimental languages. He currently spends most
of his free time researching parser theory and methodologies,
particularly areas where the field intersects with functional
language design, domain-specific languages and type theory. He can
be reached by email.

If you're feeling particularly masochistic, you can follow
Daniel on Twitter @djspiewak.