A typical conversation opener amongst programmers is the question: "What text editor do you use?" Notice that already the question is loaded: This assumes you use only one text editor, which also happens to be the one you use to write code.
Now, my "I don't care" answer is: "punch cards". My real answer to the implied question "What text editor you prefer to write code" is jEdit. Now, before I start justifying my choice of this relatively obscure and unorthodox editor, let me present you the history of the editors I used.
It all started with "ed"...
Just kidding, actually that will come back later in the story. My first editor was the script editor of HyperCard. Black and white, no syntax highlighting of any kind, 9-point Monaco font in a high-contrast Sony-made 9 inches screen of a Macintosh Classic. Of course, it used standard Mac keyboard shortcuts and mouse interface, so it was your typical "text field in a window". So, pretty easy to use and gets out of the way.
I then moved to the editor included in Metrowerks CodeWarrior when I started writing C code. Syntax highlighting, some auto-completion, standard Mac keyboard shortcuts, and some drag-and-drop. For the mid-90s it was pretty good.
And then, the "real world", that is Emacs on Windows and Solaris 8. Not that I
had a choice, as this was the standard setup offered to me at my university and
workplace. I was at complete loss about keyboard shortcuts, the 3-button mouse,
and so on, all for no apparent reason other than apparently bad UI decisions
made 20 years before. I did learn to use Emacs quite quickly, but many things
kept seriously annoying me. Its concept of "meta key" was hazy when dealing with
3 different platforms (Mac, Solaris, Windows). Text encoding support, especially
UTF8, which was critical for my work, completely sucked. What was it
again? "C-x<ret> f utf-8 C-f hello.txt". As you can guess, Emacs has poorly
chosen keyboard mnemonics that predate mid-80s GUI conventions, compensated by
some crude menu system accessed by the mouse of the cryptic Meta-backtick (which
is a pain to write on non-US keyboards). Also, having to support somebody else's
Elisp macros made supporting somebody else's Perl code look easy in comparison.
Of course, I had to try Vim too. From what I heard, all programmers supposedly fall in either the Emacs or Vim camp. So I read through the tutorial, re-learned the keyboard shortcuts again... And this is where it lost me. While Emacs has some kind of menu system to run commands if you forget the keyboard shortcuts, Vim has pretty much nothing other than "search the manual". And while the mnemonics chosen for the commands seemingly make more sense, they are often used with modifiers (length, repetition, register number...). Those modifiers, when combined with regular expressions, make running a find-replace command feel like writing code in your head. This is like the Latin of UI. Or having to write code to write code.
So, programmers are supposedly stuck in this false dichotomy of bad UI A (Emacs) and bad UI B (Vim). Both require so much mental training and investment before such learning becomes profitable compared to dumb plain-text editors that, in the end, you'll spend more time justifying your own decision and its expensive mental investment to yourself (and others) than asking yourself if there's something better for you out there. Basically, ideology applied to text editing. Ugh.
So, knowing what I wanted out of a text editor, I pretty much looked for a free cross-platform clone of BBedit, or something close to it. Something that edit text, has syntax highlighting, doesn't suck at character encoding, has standard shortcuts and can perform rectangular selection with the mouse. jEdit covered all of this, takes minutes to learn, and more.
Now, I've heard countless arguments against using the mouse to be productive
with text editing. Maybe I was wrong to do copy-paste with the mouse when doing
heavy refactoring between code branches. In an ideal world, I should never have
to copy-paste code, so using the mouse is pointless and reduces typing speed.
Instead of using the mouse to move the insertion point exactly and effortlessly
where I want, I should instead find myself more productive typing hundreds of
times the arrow keys or estimating my jump and typing "10j20l".
OK. So I'll go hardcore, mouseless and using Ed as my text editor for a day. No fancy macros, no fancy kill rings and buffers, no encoding support. Maybe then I'll get a "vision" about why all of this cozy GUI stuff from the 80s Mac onwards is a complete waste of time for programmers.
And I got it. No, not that going pure command-line is better, because it's not, but because I started to see where the legacy of those obscure conventions in Sed, Perl, Vi and Vim came from. While Emacs felt like it was cooked up in the mind of a single, somewhat insane person (no further comment), Ed's design was rooted in the harsh limitations of pre-80s computing, when network speed was measured in bauds and a full-fledged text user interface was too costly. So, yes, you had to carefully think-before-you-type. As those requirements relaxed, the conventions remained so that users of the previous incarnation could adapt easily to new tools.
So, while Emacs was designed in a crazy mind, Vim was engineered over decades of use and transformation. Either way, both editors, while highly flexible, don't seem to be in touch with the rest of the software industry, stuck in some kind of time warp. You may feel proud of editing your XML file with Vim over an SSH connection, but I'll do the same in jEdit after simply opening the same file through an SFTP connection and enjoying its real-time XML schema-based auto-completion effortlessly, without having to read the manual a single time to set it up. And when your mind is supposed to be focused on writing code, that makes a world of difference.
This page was actually edited with a combination of Evernote, nano and Vim. See, I'm open-minded...