The Lurker

Eclipse

posted by ajf on 2002-12-14 at 03:09 pm

Incredibly, in the Eclipse build I have (version 2.1, build 200211151436), you can browse through a CVS repository using the CVS perspective, but there's no access to the "cvs log" command (to read the checkin comments history of that file). You can do it from the Resource or Java perspectives, so it's not as though Eclipse doesn't support reading the log; you just can't do it from that screen. Dumb.

Kevin says he really likes the Eclipse's CVS support. But I have to say that my experience with WinCVS — which has more than its fair share of UI bugs and quirks — was faster and easier to use. And I think the diff in Eclipse is harder to read than any other diff I've ever seen. Hell, I'd use diff -u over Eclipse's diff view if Eclipse wasn't a kitchen sink application (ie, it actually played nice with external tools).

What I want in a CVS tool is to be able to see what I've changed at a glance. In WinCVS, modified files have a fiery red blob next to modified and conflict-afflicted files. In Eclipse 2.0 on Windows at work, I get an indistinct blob (maybe it's an arrow? — I can't check right now because this Linux build doesn't want to give me even that) less than a quarter of the size of the icon next the file. WinCVS allows you to use external diff tools, and if I recall correctly when you use the standard console diff it colours inserted and removed lines red and blue respectively. And Eclipse seems to take twice as long to

When you choose "Compare to latest version from repository" on a file in Eclipse, it brings up a "structural view", which is a tree view with a whole bunch of folders and the file you're look at in the bottom. Bear in mind here that, since I only had one file selected, there's nothing else in this "structural view" to navigate to. It takes three or four seconds to bring up this view, and wastes the same amount of time again because I have to double-click the file in the tree view to actually view the diff. Sometimes I could have finished reading the diff in wincvs before Eclipse bothers to show me anything.

And when it does show it to me, again I have to squint and concentrate to find the change. Suppose you change a line which says String k = "hello"; to String k = "Hello";. Eclipse's diff will display a two pane view, with the newer version on the left (which I find counter-intuitive — would you ever drawn a timeline that way? — but I can live with it). It will select the entire line in both panes. If your line is wider than half the width of your text editing area, there's a pretty good chance that the differing character isn't visible. And the horizontal scrollbars aren't tied together — you need to scroll one pane to the right, then move over and scroll the other one separately.

Some diff views are better. In the diff you get in the refactoring wizard, for example, hitting "next change" will change the selection from the entire line just to the changed characters within that line. Other diffs are even worse, though: the "Synchronize with Repository" window, which should be an incredibly useful feature (because it attempts to make "read-the-diff-then-commit" quick and easy), will cycle through every single change twice — once in a similar way to the "compare with latest from repository" view, then it cycles through the same changes again as it scrolls through the "Java structure compare" which shows exactly which methods and fields were altered (which is otherwise a really nice feature).

Other things that have bugged me with Eclipse:

The display is very busy. My screen is 1280x1024 and it feels cluttered. I can switch the various screen-hogging panels off, but getting them back when I need them again can be frustratingly slow.
Its completion features are pretty good. But sometimes it just doesn't want to work. There are times when I will press Ctrl-Space to trigger completion, and it will unhelpfully say "No completions found", even when there are no errors in the file save for the statement I'm in the middle of writing, and I can use completion without any trouble on the same object in a different line of code.
Completion works best if you've got the source code for the classes you're working with. I was working on some Cocoon related code the other day, and I have Cocoon checked out from Apache's public CVS repository. So I tried to point it at /home/ajf/src/cvs/apache/xml-cocoon2/src/java/ but that doesn't work. The source code has to be a zip or jar file. so I had to zip up that directory and copy it to /home/ajf/tmp/eclipse-fuckers/cocoon-src.zip and tell Eclipse that it's there. What the hell is that about? I guess reading uncompressed source code directly from the filesystem was just too efficient.
This Linux build I've got at home is woefully slow. I mean, I used faster applications written in Swing when it first came out and I had a 486 running OS/2 in 8 megabytes of RAM. I've had it overwrite 10 characters of code because it thinks I wanted to completion when I typed a space five seconds ago.
On Wednesday night, I was trying to edit some sample configuration XML for an Avalon component in a javadoc comment, and it wanted to reflow the text, moving separate elements onto one line, which would have made it much harder to read. If that wasn't bad enough, when I tried to delete a space it inserted, it added four more. Repeatedly. Selecting the entire block of 50 or so spaces (OK, I admit it, I kept pounding the Delete key in frustration), it complied — then, half a second later, helpfully decided to put one back in.
I saw a near-total solar eclipse in Honolulu back in 1990 or 1991. It was much cooler. I bet you can't even go a little bit blind using Eclipse.