The humble (and often, not-so-humble) text editor. It can be a wonderful thing. I know more than a few people who are zealous about their editors, and view them in the same way that they view their toothbrushes. Yes, they’re that hardcore.
Having said that, I know more than a few people who actually shy away from text editors. Why? Because they view editors as strictly a programmer’s tool. Nothing could be further from the truth. Even though I’m not a coder of any stripe, I find a text editor to be a valuable tool. More than that actually. For me, a good text editor is indispensable.
You might be writing an article, either in straight text or with a markup language like Markdown. You might be editing the HTML of your web site. You might be peeking at a shell script. Or you might just be taking a peek at a README file or change log for some software that you’re about to install. Pulling those kinds of files into a word processor is overkill.
Those are situations in which text editors are very handy. But with so many editors out there for the Linux desktop, how do you choose the one that’s for you? And by you, I mean someone who isn’t a software developer or (too much of) a techie. Someone who thinks that C is the third letter in the alphabet, for whom regular expressions are an ordinary way of speaking.
Everyone has their own favourite editor. Here’s some advice I give people who are looking for the right one for them.
What to Look For
Here are four things that I look for in a text editor. Your mileage (or whatever distance measurement you use) may vary.
First, the editor should pack some form of syntax highlighting — whether automatic or which you can turn on or off with a click or two. Why syntax highlighting? If you’re looking at any kind of code, black text on a white background tends to all look the same. It really helps if tags or comments or functions have different colours from the rest of the text. I can’t tell you how many times syntax highlighting helped me find HTML tags that aren’t closed.
Second, the editor should be fairly easy to extend. I don’t mean writing plugins for the editor, but whether or not:
- I can add custom syntax highlighting definitions
- It’s easy to link the editor to an external program that can process or validate the file I’m working with
- The developers and/or user community supply plugins that can extend the editor in a variety of ways
Third, a spelling checker is a must, especially if you’re writing. Nothing more needs to be said about that.
Fourth, the interface should be clean. No ribbon a la Word 2007 or 2010. Instead, it should have one toolbar and the ability to quickly show or hide side panes (which could contain anything from a list of files to additional commands). Also, I prefer an interface with tabs rather than an old school multiple document interface or (gasp!) single document interface.
So, what editors do I recommend for the Linux desktop? Here are a few, and you don’t have to be a coder to appreciate them.
First up, Gedit. It took me a little while to warm up to Gedit, but when I did I couldn’t stop using it. Gedit has the four main features that I look for in a text editor. What do I use it for? Mainly writing, with Markdown and without, and editing web pages. Gedit has nice Markdown and LaTeX plugins, and it also has a full-screen editing mode. Perfect for distraction-free writing.
I haven’t used KDE for a long time. But when I did, I used Kate as my sole editor. All of my KDE-using friends do the same, and with good reason. Like Gedit, Kate has the four features that I look for in a text editor — its syntax highlighting, plugin support, and boomarking are great. As well, it’s clean and fast. While Kate isn’t enough to tempt me back to the KDE world, I’d definitely use it if I ever did go back.
While Geany is essentially a programmer’s tool, there’s a lot in it for the average user. And if you’re working with straight text or HTML or LaTeX, it’s a good choice. Geany also has a numer of plugins that can really beef up its set of features. Plus Geany supports Markdown, which is a nice bonus.
If you’re wondering why I didn’t mention Emacs or vi(m), I just didn’t want to go there.