Chipping the web: February 27th

To a programmer, the text editor you use is not a matter of religion. It’s much stronger than that. It’s more like love — the initial excitement and the thrill of subsequently discovered features leads to a warm familiarity and intimate knowledge – the extreme comfort of working together to create something special.

Today, I switched my customary editor. But before I reveal my newfound relationship, I’d like to review some old ones.

My first text editor on Data General’s AOS was called SPEED. The user interface was comprised of only a command line, with very little text displayed unless you asked for it. We had a saying, “SPEED kills”, because it was quite easy to trash your whole file. To “type” text out on the display, you used the “T” command. Right next to “T” on the keyboard is “Y”, which stood for “Yank” — throw away the current page of memory and read in the next page (if there is one). If you panic and exit at that point, your first 40K or so of text is gone for good.

So, a smart young systems programmer named Dave Downs wrote the first screen-oriented text editor I ever used, which he creatively named ”EDIT”. It filled the entire screen with text, and used control and arrow keys for commands and navigation. It was user-friendly, but it did not implement any form of paging, so you were limited to about 750 lines of text in any file. Doug Helton and I made a few modifications to that editor — the uncommented assembly code was not nearly as user-friendly as the editor it comprised.

Then Data General came out with a screen-oriented editor called SED (not the same as the Unix utility). It did do paging and was extremely user-friendly, except that it was dog slow. It also performed a lot of unnecessary screen repaints, as you could plainly see when dialed in over a 110-baud modem.

When I took a job working on DEC equipment, I was introduced to KED on the PDP-11, followed by its big brother EDT on RSX and VMS. I became quite good at EDT macros, and thought that would be the last text editor I’d ever need.

In 1984, I was introduced to my first Unix variant, Altos Xenix. It had no EDT-like editor. The only screen-oriented editor was vi. At first, I shuddered at the thought that different keystrokes meant different things depending on your current mode. You couldn’t just walk up to a keyboard that was already in vi and know exactly what your next keystroke might do (or undo). But I soon got used to it, and learned to love it. It’s very fast and responsive, and you can do a lot with only a few keystrokes once you know what you’re doing – without reaching for function keys, numeric keypad, arrows, or a mouse. I continued to use vi for many years on different Unix platforms, and even when I started developing for MS-DOS and Windows, I used the MKS Toolkit version of vi for a couple of years.

Then I was tempted by the allure of graphical interfaces and the promises of syntax highlighting. I found WinEdit, and customized it for the language I used most at that time. A year or so later, I discovered SlickEdit at the SD West Conference. I was so impressed with its flexibility and capability for customization, that I helped to convince Synergex to adopt it as their IDE on Windows. They have since integrated their compilation engine into SlickEdit to create a highly intelligent user interface for programming Synergy/DE. I also used it for all the other languages in which I program, because it comes with customizations for almost any syntax you can imagine — C, C++, Delphi, Ruby, PHP, Perl, JavaScript, HTML, XML, etc.

But recently, I’ve fallen out of love with SlickEdit. It’s too slow starting up, and all that intelligence takes some horsepower. Sometimes it will hang for a moment or two while it parses an XSD or looks up a structure in the Synergy Repository — whether I asked it to or not. To do everything on the keyboard requires a lot of control and function keys, along with a good memory — so I end up reaching for the mouse a lot. And sometimes, the syntax highlighting gets confused by alternate usage like nested /* comments in Delphi. Incorrect syntax highlighting is worse than no syntax highlighting at all. SlickEdit also requires a license key to be entered whenever it is installed — which happens every time I upgrade Synergy/DE. The final straw came when I swapped out my last 32-bit Windows development system. SlickEdit isn’t available in a 64-bit Windows version yet, and the 32-bit version runs even slower under 64-bit Vista than it did on slower hardware under 32-bit XP.

Of course I’ve used other editors on Windows. Visual Studio gives you half the features at half the speed. There are Notepad+ and SciTE, which look interesting but don’t present anything fascinating enough to draw me in. Besides, they’re still trapped in 32-bit land on Windows, too.

So I decided to go back to my best love, who has since gotten all dressed up for the occasion: vim. She’s available in a Win64 version. She sports a ton of new features, but she’s still just as responsive as ever. I slipped into working with her like I’d only left her yesterday (in fact, I’ve continued to use vi occasionally on Unix, so I haven’t forgotten too much).