Some people reading this post will already know about the bug of which I speak. For those of you who are unaware, I give you Eclipse bug 8009. This is the Eclipse Bugzilla entry for the absence of split editor windows in the popular IDE. The bug is now over 10 years old. The bug has a very rich history, and I encourage you to read through at least a portion of the thread. One of my favorite parts is at the very end of the comment history, where folks raise a glass to toast the 10 year anniversary of the bug. I also enjoyed the attempt to fill a virtual tip jar with money to bribe the developers to implement this feature. It looks like they raised at least $270.

I recently had the unfortunate experience of revisiting this bug (hadn’t seen the thread in a while) because of the newly released Eclipse 4.2 (Juno). At SlickEdit, we are currently working on our next version of the SlickEdit Core for Eclipse plugin, which will be built on Eclipse 4.2. In Eclipse 4.2, the split editor window problem has again become a major hurdle. I’ll refrain from voicing any dissenting opinion about the new UI released in Juno, though all the criticism seems to be warranted, and focus on the issue at hand. Several plugins, ours included, have implemented their own ways of providing split editor window capabilities within Eclipse. These implementations may have relied on internal APIs (bad practice), but there was no publicly available way to go about providing this feature. So we did what we had to do to provide what our customers wanted. Eclipse sure didn’t seem interested in actually providing a way to split an editor window in their IDE (remember, 10 years). And please don’t say, “Click and drag the window.”

Enter Juno, the new Eclipse workbench UI, and API changes which have broken these implementations. Of course there is no guarantee that internal Eclipse APIs will not change or break between releases, so this to no fault of Eclipse. Although maybe if the bug was addressed sometime in the last 10 years this wouldn’t be such a problem in the first place.

For now we are left searching for another workaround, and checking the status of this epic bug. The comment history has gone through a civil phase, a nasty phase, and then what seems to be phases of disbelief, and now acceptance. I really just wanted to share this thread to some who might not have seen it before. Maybe now you feel a little bit better about some of the long-standing bugs in your code. I hope we don’t ever have to toast them.

In this first video on SlickEdit’s DiffZilla feature, we demonstrate comparing two source directories and show how to perform a quick file diff of two open documents.

In future videos we’ll cover more advanced usages of DiffZilla, including Backup History and version control history comparisons.

Note: this video is best viewed in the  highest quality setting available for your browser. You can set the quality via the video’s bottom menu bar after selecting to play the video.

“…I’ll answer the question. You want answers?”

I think I’m entitled.”

You want answers?!”

I want the truth!”

You can’t handle the truth! Son, we live in a world that has walls, and those walls have to be guarded by men with guns…”

The above comes from a very famous movie allegedly based on the life of a lawyer that runs those ads on TV now.  I don’t mean to imply that makes him better or worse than any other lawyer – people have to know you’re out there, and we don’t have yellow pages anymore.  It’s a great scene… I’m not going to mention the name of the movie… not because of any copyright or anything.  My premise started with the fact that the movie, and that scene in particular, are so famous that everybody will recognize it.  I’m sticking to that.

But right now,  want the truth – about the current directory of the tool I am in.  My responsibilities here at SlickEdit sometimes require me to use development tools that are not SlickEdit.  And whenever this happens, I find it difficult to figure out what directory I am in.   And this is not an indictment of a sole tool, although the one that prompted me to leave it and start this rant seems to be the worst offender.

Is the directory that my project is in a secret? Is there a dark piece of history surrounding the location of these files that have caused their family shame, and they don’t want me to know?  Do they think that I “can’t handle the truth”?  Am I the only user of these products in history to have to switch between two copies of the same project and try to figure out why one works and one does not?

I’m a big boy. I can handle it.  Just tell me.  And floating over a tab to show me where an open file came from is not good enough, because I don’t know if it is the one in that project or not.

For those of you who feel the same way, in SlickEdit you can go File>Change Directory to view (or change) the current directory.  You can also go to the SlickEdit command line (click on the status bar to the left of the Line indicator) and type “cd”.  Or if you speak UNIX you can type “pwd” if that makes you more comfortable… but typing “cd” by itself will not make the current directory of the editor your home directory.

Upon further review, I must admit the whole analogy falls apart somewhere around the part about “those walls have to be guarded by men with guns…”   But I love the line You can’t handle the truth!”.  But in this case, I can.  I just want to know what directory things are in.

« Previous PageNext Page »