I write most of my code in Ultraedit and when I’m writing java I really want to be able to access javadoc documentation for the Sun API as quick as possible. This is a description of the evolution of a little utility to look up javadoc documentation very quickly.
I know that IDEs like IntelliJ and Eclipse offer in-window documentation tooltips (this is actually executed best in Microsoft’s Visual Studio.NET of all the IDEs I have used). But these horking great programs put me off because they feel clunky and tend to specialise in one language. I prefer to use the tricks I learn with my text editor with everything I am working on rather than learning a set of shortcuts, etc. for every language. I know Emacs has tagfiles for every language and is on zillions of platforms but it doesn’t feel like a native Windows app and as that’s where I spend 99% of my time it just doesn’t cut it. Ultraedit makes me feel nimble and encourages cross-application serendipity.
I used to bring up a Run box with Win-R and write the full path to file I needed. So to get the docs on java.util.HashSet I’d do:
Win-R, "c:docsapijavautilHashSet.html", Enter
(obviously autocomplete would make it a little bit quicker than that). This was far too slow – interrupting your train of thought to look up documentation.
To speed things up I dropped a copy of every HTML file into the docs folder. So to get the HashSet documentation I need only type:
Win-R, "c:docsHashSet.html", Enter
(again with autocomplete speeding me up). This wasn’t too bad speedwise but all the links in the file launched would not work. So if you wanted to look at the docs of a superclass or of a method’s return value you had to go back to the Run box. Not ideal.
It seemed the only answer was to write a little utility. I chose Perl as it’s filehandling is simple and the language itself pretty fast. The code I ended up with after a first pass was:
#!c:perlinperl.exe
use strict;
use warnings;
$ARGV[0] || die "No arg supplied.
";
my $look_for = "/" . $ARGV[0] . ".html";
my @found;
my @files = search_dir("c:/docs/api");
if (@files == 1) {
print "c:/progra~1/intern~1/IEXPLORE.EXE " . $files[0];
exec("c:/progra~1/intern~1/iexplore " . $files[0]);
} else {
# FIXME
}
sub search_dir {
my $dir = pop;
my @list = glob($dir . "/*");
foreach (@list) {
if (-d && $_ ne $dir && ! /class-use/) {
search_dir($_);
} elsif (/$look_for/) {
push @found, $_;
}
}
return @found;
}
I had to put in special cases so that one directory was not traversed indefinitely and to avoid the class-use directories that are not of interest (they contain links to classes that used the class).
This worked just fine (excluding the failure to handle multiple matches) but had a noticeable delay. The time I saved typing:
Win-R, docs.pl HashSet, Enter
compared to the longer version was lost in the searching of the filesystem. Worse the time was now idle time instead of active time and that seems longer (think of waiting for a bus).
What was taking the time was traversing the filesystem looking at filenames.
So I decided that work could be done just once and cached. I ran “find” at a Cygwin bash prompt from the api directory and put the output in a quickref.txt file. I used “grep -v class-use” to remove the class-use directories and replaced /c/ (my symlink to the root of the C: drive under Cygwin) with c:/ to produce a list of paths to all the relevant files.
Now all I needed was code to read this file and find the correct entry.
#!c:/perl/bin/perl.exe
use strict;
use warnings;
$ARGV[0] || die "No arg supplied.
";
my $look_for = "/" . $ARGV[0] . ".html";
open(FILE, "<quickref.txt");
while (<FILE>) {
if (/$look_for/) {
exec("c:/progra~1/intern~1/iexplore " . $_);
}
}
This code was a good deal shorter (the work’s largely been done in creating quickref.txt) and faster. I speeded it up even more by forcing Internet Explorer (quicker startup time than the otherwise superior Firefox) and short-circuiting at the first match (only conflict that occurs often is java.sql.Date and java.util.Date anyway).
All that remained was to create a shortcut on my path to the file called ‘d’ allowing me to launch (for example) fully linked HashSet documentation with:
Win-R, "d Hashset", Enter
A future version could generate the quickref.txt file if it is not present. But as this is such a simple utility I doubt it will have a future version. Other javadocs can be simply added by appending their paths to quickref.txt. Obviously the browser commandline should not be hardcoded and I could consider respecting ESR’s $BROWSER attribute. If you think this is overkill or have suggestions for improvements or just simply think I’m a nutter please comment below.
