Automatic hyperlinking in a terminal emulator

You know how sometimes you implement something and then every time you use it – until you become blasé – you ask yourself why you didn't implement it years ago, it's that useful?

I just added something like that to the best Unix terminal emulator.

It's not finished yet, and it's only in the nightly builds (available from my home page), but already it's great. It's the best thing to happen to terminal emulators since we added really awesome find functionality.

What I did was this: we now assume that the window title (set via the usual escape sequence in your bash prompt) is the name of your current directory. If we see text output that looks like it might be a filename, we check whether appending that to the window title gives us the name of an existent file. If it does, we turn the text into a link that puts the file in your editor.

You have no idea how cool this is.

I implemented it with only grep -n in mind; I wanted to be able to click on grep's output and go straight there in my editor, just like I can already do if I run grep within the editor. Now I can. But it's better than that. I didn't realize until I ran it, but it works for ls too. All of a sudden you're looking at a clickable list of files. Choose one and boom! You're in your editor, looking at the file. Do a bk pull to get the latest changes, and see a file you're interested in has changed? Click on it. Boom! It's in the editor.

I broke the URL linking for this, but it's so worth it. I did see a few http: links, but never wanted to follow one. I never saw a mailto: link. A "Connect to Server" menu item would be a better replacement for the ssh: and telnet: links I never saw either.

Filenames, though: they're a shell's bread and butter.

You don't get this kind of adaptation to your way of working with a typical IDE, and that's is why I don't like them. You don't have the freedom to work how you choose, with the tools you choose (or have available, or are forced by circumstance or policy to use); at least not if you want the full power to be available to you. And what they give you in return is rarely worth the price you pay.

(I'm happy to call my editor an Integrating Development Environment, a term probably coined by Rob Pike or Charles Forsyth in reference to the acme editor, though. "Integrated" sounds like the job's done. "Integrating" admits that it's barely started, will never finish, and – for the time being – should be the IDE's job, not the job of each and every tool.)

Times are changing, and in many cases bad APIs and bad systems are forcing us into IDE straightjackets because otherwise life's too hard to bear. But these API-softening tools only tend to exacerbate the problem. Have you ever had to work with IDE-written GUI code? Then again, have you ever had to work with GUI code written by the kind of less-skilled developer that lets an IDE write their code for them?

Which would you like? The rock, or the hard place?