Nick Farina

Update: I wrote a plugin to address these issues.

Later Update: Xcode 4 Preview 3 shipped with a brand new completion engine and UI that happens to address all these issues with aplomb. Yays!

The newish mac app Espresso contains a great (and uncommonly beautiful) implementation of code completion.

It goes like this. Say you’re editing a CSS file:

That’s a nice blue background, but you also want a border. You start by typing the letter “b”:

Since Espresso knows that there are many possible options that start with “b”, it presents them to you in this lovely but minimal popup. You can use the arrows and press enter to select something from the list. Or, you can pretend the list never appeared and keep typing. Once you type enough to eliminate all other options, the list disappears and you’re left with a more standard OS X “completion” highlight. You can still press enter to accept this last suggestion.

The two things I want to emphasize about this workflow are:

• It’s predictable. I trust Espresso to always give me all possible relevant options after each keypress. And I know that I just press enter to accept and move on.
• It’s useful. Whenever there are multiple options, they are presented to me in the list, and the list appears automatically when needed.

Predictable

XCode goes like this. Say you’re writing some Objective-C:

We need to make a new instance of UIViewController, so we begin our journey of typing the class name.

XCode does nothing so far. We know it has a set of suggestions to help us—if you press ESC now, you’ll see a nice list of all the classes starting with “UI”. But for some reason it’s decided not to jump in yet. (Note: My Code Sense delay is set to Immediate). We press on, typing “v”:

Ah ha, there it is! Clever XCode! That’s what we want—so we’ll press enter:

Curious. It has only partially completed the word. See how before, only the ‘i' was highlighted? This is a (newish?) feature of XCode. It turns out there are a few other classes starting with the prefix “UIVi" and it doesn’t want to assume that I want something starting with UIView and not, say, UIVideoEditorController which I never knew existed until just now.

At this point if I press enter again, it will go ahead and fill in the rest of the word.

So it eventually gave me what I wanted. But here’s a wrinkle: if I would have typed “uivi" myself first, it would have suggested UIViewController just the same, but in that case it would have completed the entire word when I pressed enter.

The problem here is that XCode is not predictable. When I’m typing code, my brain is moving faster than my fingers. I can decide to type [[[UIViewController alloc] init] autorelease] a hell of a lot faster than I can actually write it. And my brain can’t move on to a more interesting problem until it can give my fingers a known sequence of keys to press. XCode’s completion is a different back-and-forth conversation with the editor every time. How do I get it to finish UIViewContoller? Do I press enter once, twice, three times? It depends how many characters I typed first, which also depends on factors like XCode tailoring its suggestions based on my code history.

Useful

Here’s another example. Let’s set the frame of our new controller’s view, by first declaring a new CGRect:

Now here I’ve typed the letters cgrect just like that, and XCode hasn’t suggested anything at all. Maybe I have to type more than 6 characters before XCode jumps in? (Nope, that’s not it.)

OK well, I’m done typing now, so I have to fixup this cgrect by turning it into a real CGRect with proper caps. Maybe XCode can help with this? I’ll press ESC.

OK, so I got lucky, it happens to be the 2nd item in the list. (If this list was sorted alphabetically, as it is by default, CGRect by itself wouldn’t even be on it). But still, I’ve written an exact match, shouldn’t that be what’s selected by default instead of CGRectInset? Now I have to fiddle with arrow keys and scrolling and by this point I could have just typed out CGRect myself with proper carpal-tunnel-inducing capitalization and skipped all this business.

It gets worse

These are just two examples out of many. In fact, XCode’s completion is so unhelpful that I can only assume the engineers at Apple never have it turned on, and maybe just code everything in Vim anyway. To me, it feels like the sort of feature that was built to “satisfy” demand from non-Apple developers. Look, fine, we’ll give you your ‘completion’, you Microsoft-coddled sissies, now please go away and let us work on OS X 10.7 already!

It’s just a bit sad for me, because I have tasted the sweet nectar of real, predictable, useful code completion, and it is wonderful and productive. This isn’t an intractable problem! It just needs some more TLC.

If you agree with my findings, I encourage, nay, command you to go fill out a bug report with Apple (they really do read these).

I have also reposted the issue on Open Radar.