A good text editor is, by far, the most important tool for programming computers. There are many good options available, and each person has their own reasons for choosing one editor over another. On the Mac, popular choices include BBEdit, TextMate, and Coda. For modest needs, an editor like TextEdit.app can be sufficient, while some opt for a full-blown IDE like Eclipse or XCode. Many coders still work with a console-based editor, such as vim.

I haven’t had a Windows box in so long I’m not sure what the popular choices are any more, but in college I was an UltraEdit guy.

My text editor of choice now is jEdit, which is free and Open Source. jEdit is written in Java, so it works on both Mac and Windows, and it supports many of the same features of non-free editors. It seems to be pretty obscure though, in part because getting jEdit into a usable form takes a little bit of work. Plugins must be installed, settings must be tweaked. It uses ugly non-system native Open and Save dialog boxes, but I don't mind so much because those interfaces let you work with remote files seamlessly via SFTP (using the 'FTP' plugin).

I thought it would be helpful to share my preferred settings, to give my favorite editor a better first impression. Below are a few steps to help you get set up on a Mac or on Windows. Desktop Linux can probably also follow along and improvise where things might diverge from Mac OS X.

1. Start by downloading and installing the latest stable release, use either the Windows Installer or Mac OS X package
2. Download and unzip my baseline configuration: jedit-mac.zip or jedit-win.zip (these have different default fonts and keyboard bindings defined in startup/startup.bsh)
3. Launch jEdit once to generate some default settings, and then quit (on Windows you may also need to close the jEdit Server from your system tray)
4. Make a backup of the default settings folder, found in /Users/[username]/Library/jEdit on Macs or C:\Users\\[username]\\.jedit on Windows 7, just rename the folder to jEdit.bak or .jedit.bak (note: your Library folder is hidden by default in Mac OS X 10.7 Lion)
5. Copy my baseline configuration folder where the default one was (in your Library folder on Macs or in your home directory on Windows)
6. Launch jEdit again, it should look a lot nicer!

Some notes about what’s different in this configuration:

• Nicer color scheme and default font (via the Editor Scheme plugin)
• FTP plugin for seamless remote file management (use a path like sftp://user@hostname/path/to/directory)
• Tabs UI instead of a drop-down to switch between files (via the BufferTabs plugin)
• Project Viewer plugin lets you browse files from the sidebar
• XML plugin provides handy HTML auto-completion, indentation, and entity conversions
• SuperAbbrevs plugin lets you set up macros for frequently used code snippets (for example type 'a', then shift-tab, set a macro for hyperlinks like <a href="$1">$end</a>—now you can type 'a' followed by a tab and save yourself some repetitive typing)

You also get things like multi-line tab indenting and regular expression search/replace out of the box. Of course you'll want to tweak your own setup further depending on your needs, so be sure to explore the preferences and browse the extensive list of plugins. One thing that's also worth pointing out is that jEdit listens on a random network port when you start it up to determine if other copies of the editor are running. When I first saw this it made me wonder if I should worry that my editor had been hacked, but apparently this is normal behavior and can be disabled.

In a pair of recent posts, Andre Torrez outlined an idea for solving the “how do I get photos from my iPhone onto a website” problem. I like this idea, and I’d happily install this hypothetical Community Camera app if anyone ends up developing it.

The central mechanism for Andre’s idea is a new URL protocol camera: (similar to http:, mailto: or ftp:) that a simple camera application could claim control over. One such built-in protocol on the iPhone is sms:, which lets you easily direct users to send an SMS message. For example, clicking on this link (with URL sms:+12125551212) would switch you over to the SMS application with the phone number already filled in. Here is a handy list of other iPhone-supported protocols. But if you’re not reading this on an iPhone, pressing that link will probably give you an error message.

One of the good design aspects of hyperlinks is they’re not always expected to work, the web is chaotic and broken links are relatively harmless. So it’s certainly okay to offer these links even if they won’t work for everyone. An improved design would allow web applications to detect whether or not a given protocol can be used. That way I could write some JavaScript code to check whether camera: or sms: links are supported, and make the process much more seamless for users. As far as I know (correct me if I’m wrong), such a mechanism doesn’t exist yet. It exists! See update below.

The email workaround

One workaround solution, used by many web applications including Flickr, is to provide a special email address that allows you to upload photos as an attachment. The benefit is that every computer with a browser supports email links, smartphones and otherwise. The downside is the unwieldy sequence of steps you have to follow. In the best case scenario, a user has already saved the web app’s special email address to her contacts:

1. Switch to the Camera app, take a photo or find the one you want from your library
2. Press the “utility button” and choose “Email Photo”
3. Fill in the email address from contacts and press send
4. Switch back to the browser and wait for the attachment to be received by the web app

A number of factors complicate this process, starting with the initial messaging. The natural thing to say is “Email a photo to upload,” linked with a mailto: URL protocol. But on the iPhone you can’t attach photos from the Mail app, it only works from the Camera side of things. So that “Email a photo” link should probably go to a page that explains the process outlined above, including the important step zero “add our special email address to your contacts.”

Email uploading requires that you’re willing to read a bunch of steps, understand them, and follow them. Additionally, the web application is left with no button that initiates the process and no way of giving feedback about whether it worked or not. If you reload the web app and you see your photo, then it worked. If not, maybe you’ll get a email bounce message. It’s a process that works okay for experienced users, poorly for novices, and that fails ungracefully.

Plus there is the implementation challenge of receiving and parsing email, which is kind of a pain in the ass. As an alternative to Andre’s plan, if somebody wants to write a general purpose email-to-upload service, I would find that pretty useful. Or does this exist already? I haven’t looked very hard.

Compare those steps above to the camera: method (including step zero, “install the Community Camera application”):

1. Press the “upload photo” link, with its “camera:” URL protocol
2. Using the native app that appears, take a photo or choose one from your library
3. When finished, the app switches you back to a page that has useful feedback

This is a better user experience, but it does require that someone go and write that native camera app (and that I install it). And unless there’s some way of checking for camera: support, even this will require some additional explanation.

Multimedia Messaging Service

Yet another solution can be found in SMS, or its more advanced permutation MMS (Multimedia Messaging Service). Using the sms: protocol mentioned above, I could create a link to sms:email@example.com that behaves almost exactly like the email upload method, while avoiding some of its complexity. On the iPhone, you can attach photos from the Messages app, and you can send MMS messages to an email address. And since there’s a link that initiates the process, it allows web apps to give some feedback on the page in response to a click event.

The downside to this method is that it requires the user to have a mobile plan with reasonable rates for sending MMS messages, and could fail ungracefully for users who aren’t fully informed about their mobile plan.

In any case, writing all this up has made me realize web browsers should let you detect whether a given URL protocol is supported. Browser makers, please build that into your next release!

Update: Andre tweeted a clever trick for detecting URL protocol support! Here’s how it might work in PHP:

<?php

// This will only work if the sms: protocol is supported
header('Location: sms:email@example.com');

// If not, fall back on this other page
echo '<html><head><meta http-equiv="refresh" content="0; url=sms-not-supported.html" /></head></html>';

?>