Category Archives: Navigation & Browsing

Post navigation

We all have our favourite diff tools for comparing files and it’s probably not Eclipse itself, unless you’re comparing version controlled files.

But sometimes you’ll want to compare two files from within Eclipse (whether they are in your workspace or external files) either because it’s quicker or you don’t have your own diff tool to hand.

Eclipse offers two ways of comparing files with each other. One of them is appropriately called Compare with Each Other. Although this is often the suggested way to compare files, it’s not easy to use and doesn’t work with external files. This post will focus on another Eclipse feature called Compare with Other Resource that makes things go a bit smoother and handles external files but it will also cover using Compare with Each Other.

Java classes can get big and hairy, making it difficult to find the method you’re looking for when browsing or editing a class. There is no specific order to where methods can be in a class and different developers have different preferences about where to put them.

You could use the mouse wheel and scroll ferociously until you eventually find the method or you could even use Page Down/Page Up on your keyboard. But these methods can be time-consuming and haphazard, especially when the class has lots of methods or they’re scattered in an arbitrary order.

Luckily, Eclipse has a number of fast and easy ways to help you navigate methods in a class, especially using the keyboard. I’ll discuss some of those keyboard shortcuts and also which ones to use when.

Something you do a lot in Eclipse is open files such as classes, XML files and property files in editors. But using the mouse to hunt through the Package Explorer folder hierarchy takes a long time, especially if you forgot where the files are located. The problem gets worse the more projects and files you have in your workspace, so there must be a better way of opening editors.

Luckily, Eclipse has a number of ways to open editors easily using the keyboard. Couple these with oodles of keyboard shortcuts to navigate between editors once you’ve opened them, and you’ve got enough tools to stay away from the mouse and make coding go a lot faster. I’ll discuss some of the more efficient options and then give a summary of when to use which method.

Whenever you hover over any piece of code in Eclipse, it pops up a tooltip that displays more information about the item, such as its declaration, variable values or Javadoc information, as in the example below.

Although useful at times, this becomes extremely annoying after a while, especially when you’re using your mouse to browse some code. Popup after popup of unwanted information keeps obscuring your view of the code, leading to some lengthy expletives and big productivity loss. It’s useful information, but not every time all the time, almost like your car’s GPS giving you directions to 10 different places at once while you’re still parked in the driveway.

Luckily there is a way to alleviate the problem and all it takes is changing some preferences in Eclipse. We don’t want to completely disable tooltips (they can be useful), so I’ll show you how to tell Eclipse to bring up the tooltips only when you request them.

You’ll often end up with a lot of open editors in Eclipse and consequently needing to navigate between them. You can use the mouse for this, but that often disturbs your flow when your typing, slowing you down.

That’s why there are a number of ways to navigate between editors in Eclipse using only the keyboard. Combined with the ability to quickly navigate views using the keyboard, it’s an easy way to work faster and almost get rid of the mouse (reducing company spending… well, slightly).

If you’ve been hanging onto one Eclipse workspace for the last couple of years, you’ll probably have dozens of projects cluttering up your workspace. If you’re an Eclipse RCP developer, you may be sitting with around 50+ projects easily.

The thing is that you’ll often only work with 1 or 2 at a time, not the whole lot. And sometimes you want a convenient way of only browsing projects belonging to a specific product/feature/layer/any-other-grouping-that-makes-sense. Having all projects in a long list makes it difficult to manage and more difficult to browse.

That’s why the Package Explorer and Project Explorer have a nice feature that reduces the clutter and allows you to organise your project into categories that make sense. So instead of the Package Explorer looking unwieldy and flat like this,

When working with SVN, CVS or any other repo, there are some things you’ll just do over and over again. Things like committing files, comparing files and viewing a file’s history are all commonplace actions.

So you might be wondering where the keyboard shortcuts for these actions are, because, as I mentioned before, you normally work faster with keyboard shortcuts than jumping between the mouse and keyboard all the time. And often the longest part about working with repos is guiding your mouse through treacherous context menus and submenus.

The good news is that there are keyboard shortcuts in Eclipse for the most common repository commands (and not-so-common as well). The bad news is that most of them aren’t configured by default, so you need to set some of them up beforehand. But the 2 minutes spent configuring these may save you hours in the long run.

I’ll be using SVN as the example repository (using Subclipse) but these should apply to your favourite repository integrated into Eclipse (I know that the in-built CVS has these commands as well).

I really don’t like it when Eclipse shows errors/warnings annotations in a class. It’s sometimes nice to jump from one to the next and clean out a class one line at a time, but most of the time they’re just distractions, so I want to be able to find and fix them fast.

So there must be a better way to jump between the errors/warnings than to use the mouse or page down to the next error. These methods are not only slow but often frustrating because you tend to miss the annotation, especially if it’s a big class. And navigating to the Problems view using the keyboard is ok, but sometimes overkill for just clearing out errors/warnings in one class.

A good thing then that Eclipse offers keyboard shortcuts that take you to the next/previous annotation in the class. And it does so in a way that selects the annotation immediately, allowing you to use Quick Fix (Ctrl+1) to fix it fast. So here’s how to use these shortcuts to navigate between the error/warning annotations and fix some of the errors easily.

With so many views in Eclipse (around 50 for a default install), it can become difficult to navigate them all, especially when you don’t want to reach for the mouse all the time. As I’ve mentioned in a previous post on how to manage keyboard shortcuts, learning how to use the keyboard efficiently can save you oodles of time later on.

Fortunately, Eclipse has a number of ways to navigate between views using only the keyboard. I’ll discuss the Show View shortcuts, the Show Views dialog, Quick Access and then view cycling, with some advice on when to use which one. There’s also a bonus tip on how to activate the editor with the keyboard once you’re done with a view.

I spend a huge amount of my programming time in editors, editing, switching between them and closing them. This means that managing editors has to be as efficient as possible, which means that, for one thing, I shouldn’t be swapping between the mouse and keyboard all the time to work with editors.

Luckily, there is a way to manage editors using the keyboard (and it doesn’t involve the laborious Ctrl+F6). It’s a feature called Quick Switch Editor and it makes working with editors a lot more enjoyable.

Quick Switch Editor works by popping up a list of all open editors (sorted by editor title) to the right of the editors tabs. The list is searchable so you don’t have to navigate long lists with the arrow key and searching supports wildcards. On top of that, you can also close editors from the list. Here’s a quick glimpse of what it looks like: