Actually, this IS your father's text editor

July 9, 2008 ⋅ 11 Comments »

This week, I’m doing all my coding on a borrowed MacBook. It’s the most time I’ve ever spent doing development on a Mac. I’ve done a bit here and there on my Mac Mini, but usually I just use that for web browsing, downloading episodes of Degrassi High, and such.

Of course I needed a text editor, so I figured I’d give TextMate a try since it’s highly recommended by many Mac hackers. My first impression has been good. It’s a got a nice, simple, no-frills interface, some slick built-in themes (Espresso Libre ftw!), and the bundles come in pretty handy.

I’ve found a few small things that have thrown off my rhythm though. The regular find command (⌘-F) doesn’t do an incremental search, and hitting Enter again doesn’t bring up the next match. Yes, I know about Ctrl-S, but geez, I gave up Emacs like eons ago, and I’m just so used to typing Ctrl-F (on Windows) or ⌘-F (on the Mac) to search. And I want it to work that way in every application.

Another thing that I miss is the way the Home and End keys work on Windows: they move the cursor to the beginning and end of the line. On the Mac, they take you to the beginning and end of the file, which you can also do on Windows by hitting Ctrl-Home and Ctrl-End. I really miss the Windows behaviour, because it’s my favourite way to nuke a line or a whole section of code: whack Home, then hold down Shift and use the arrow keys to select the lines you want to kill.

Anyways, the point of this post is not to complain about TextMate, because it is a fine piece of software, and I’m sure it won’t take long for me to adapt. But this experience got me thinking about the whole experience of programming in a text editor, and made me realize that this hasn’t really changed much in 30 years.

Where’s the innovation?

In 2008, on almost every operating system, your choices for a text editor are roughly the same:

Now let’s go back 30 years, to 1978. I wasn’t breathing 30 years ago, let alone coding, so I had to go to Google for a little history lesson. But as I understand it, here were your choices in 1978:

So where’s the innovation?

At this point, you might be thinking, who cares? Emacs/vi/TextMate is good enough. The thing is, the text editor is still the primary user interface for coding. That’s why some people get so religious about their preference. It just seems weird to me that there have been so few attempts to try something truly new. And I find it hard to believe we reached the pinnacle of programming UIs in 1978.

A few ideas

Most editors are just as good for writing a blog post or screenplay as they are for writing code. But the structure of code is completely different. You rarely open up a source file and read it from beginning to end. But most programming environments seemed to be designed for that kind of workflow.

In the end, I think that’s the real kicker: most programming languages are file-based. For some reason, we seem to be so attached to coding in plain text with 80-character lines. If you drop this assumption, things start to get a bit more interesting. But that only takes us to where Smalltalk IDEs were at in the 80s.

Anyways, most of the dynamic languages aren’t inherently file-based. By that I mean that it’s not too difficult to interface with the interpreter without using text files. So that’s not a good excuse.

Here are a few things I’d love to experiment with in a programming environment:

What do you guys think? What are your favourite programming editors/environments, and why? Any other ideas about how programming UIs could be shaken up?


  1. David Mathers - July 9, 2008:

    Vim can already do much/most of what you ask for. The barrier is that to enable those features you have to learn about vim configuration and plugins, which can be daunting. What vim really needs is an easy and convenient way to manage the functionality that is already available.

  2. Jeremy Handcock - July 10, 2008:

    Great post, Patrick. This seems like a ripe area of research opportunities!

    Me, I use Eclipse for Java and vi for everything else. This is mostly because they are the standard tools and I've never bothered to see if anything better is out there. Maybe I'll give TextMate a try.

    It's not quite yet dead, but code visualization (ie. heat maps for profiled code) has never really caught on in a big way. I'm not sure why that is.

    Your thoughts on supporting exploratory programming in an editor are really interesting. I'd like to see this in my editor for sure.

  3. Patrick - July 10, 2008:

    @David Mathers: Really? Can you give me some details about the vim plugins that can do this kind of thing?

    @Jeremy Handcock: Interesting, I've never seen that kind of code visualization before, but not surprised that someone else has thought of it. I guess for profiling, the reason it's probably never caught on is that (a) most people never profile their code, and (b) finding the name of the top 5 or 10 hottest methods is usually good enough. Heat maps wouldn't be cool, but aren't necessarily that much more useful.

    On the other hand, I could imagine code path indicators in a debugger to be really useful. Imagine you pull up your debugger to investigate a crash, and it shows the code path most recently taken through the method. Kind of a lightweight version of the rewindable debugger.

  4. Boris Bokowski - July 11, 2008:

    I am still waiting for smooth scrolling in text editors, like it was implemented by Cygnus Ed (Amiga, ca. 1990), or nowadays on the iPhone. Both implementations are based on a model that make the sroll movement appear like that of physical objects, which is much easier on the eyes and brain compared to what all other text-displaying apps do. (Does TextMate do smooth scrolling?)

  5. Patrick - July 11, 2008:

    @Boris: No, TextMate doesn't do smooth scrolling. You know, it's not something I've ever really thought about, but it would be a nice touch.

  6. Nate Hollingsworth - August 2, 2008:

    I use Visual Studio for my code (my work is all C#). Its really nice, but still lacks many features or the feature is there just very ackward to use (for example Go To Definition).

    I really like your idea of turning coding text editors into hypertext. When tracking down a bug or trying to figure out why the code is so stupid, I spend a lot of time following the code path. Like you say it would be really nice to be able to see a visual code path somehow.

    I think we need to get away from thinking of code as lines in a file. In the OO world we deal with objects and methods (mostly). So, we should be working with those primitives directly.

    I completely agree that the coding environment really hasn't changed alot in the last 30 years.

  7. Miller Peterson - August 24, 2008:

    I know what you mean about the home / end commands on macs. I used to use the home/end keys in the same way, but had to give it up since I switched to mac. Command-left / command-right are like home/end for macs, but it's not the same.

    Having recently started using Eclipse for Java development after being strictly plain text-editor, I'm still getting used to all the sweet features it has - just being able to navigate method declarations and rename variables automatically is blowing my mind.

  8. Danielle Fong - August 25, 2008:

    Have you looked at Fortress? It has much more interesting typesetting; like coding in Latex, but... better.

  9. Patrick - August 25, 2008:

    @Danielle: Nope, haven't heard of Fortress before, but I'll check it out. Based on your description, sounds a bit like Knuth's literate programming.

  10. Peter Crouch - September 4, 2008:

    Personally I prefer this plain and simple old school text editor:

  11. Thomas - January 7, 2009:

    Hypertext coding? MozRepl provides live access to firefox javascript internals, but outside of, not inside the browser. (Inspired by the Read-Eval-Print-Loop of LISP, nowadays also provided by python and ruby) Now the creator of it has added an experimental module to replace the command line interface to mozrepl with a web server. This means you can access nearly all firefox internals via a web browser (be it firefox again or IE, ...). From this it should not be too difficult to fill up templates that show off variables, arrays, functions as html in a very nice and maybe even useful way. But you would still lack a decent editor based on html-technologies.