Introduction

As we’re nearing the end of the C series it becomes more and more obvious that we need to learn more about the tools, about the practical side of programming. And one essential aspect is the editor. Of course, that’s not to say that the editor is only needed when programming. While Linux has GUIs more and more advanced, given its’ heritage you will sooner or later have to use the command line and an editor you are comfortable with to edit some config file. So choosing and knowing at least one editor that’s available for Linux is more than important. Here’s what our article is here to do, and the only thing expected from the reader is patience and some free time.

A theoretical background

Don’t worry: while the subtitle might seem a little demanding, don’t expect fancy and hard-to-read terminology. But we felt the need to have a little introduction from a more technical point of view.

Linux offers a choice of editors that is too wide at times. How so? Well, if you are a beginner, you will need an editor and start searching the net with terms like “Linux editor”. In a matter of seconds you will find blog posts, forum posts, mailing list posts, articles and tutorials on the matter, each and every one telling you how editor X is the best and the other editors are no good. Confusion will ensue in a matter of minutes. This is where what you’re reading right now (hopefully) helps. We want to give you a short classification of available Linux editors, then give you a blitz tutorial on the most popular: vim and emacs.

GUI or CLI?

Although we don’t really appreciate giving advice and prefer respecting everyone’s taste, here’s a piece of advice: forget about “use that editor, it’s more 31337 than the others! You will be so k3w1, d00d!”.

So it’s an advice not to take such advice, basically. 11 cases out of 10 these are childish advice with no real interest to help you. And let’s be honest: no one sees and no one cares about what you’re using, and everything that matters is a tool that does the job in the manner you want it to. There are good GUI editors, like kate, jEdit or gedit, just the same as there are good CLI editors (and some have GUI equivalents): (n)vi(m), emacs, jed, nano, ed and others. This article will only give you a short introduction and a very short introduction to two of the more popular editors, but it’s up to you to search for the aforementioned names and even try them on to see which fits your hands better. You might have noticed that we haven’t included some popular Linux IDEs in our list, like Eclipse or KDevelop. While some of the most complex editors named above can serve as IDEs, I personally believe that with the right mind set, any editor can become an IDE, and some, like vim, emacs or kate, are already believed to be IDEs if used correctly. So the botton line is: try them all and see (this is why you were asked for some free time in the introduction) for yourself. Use every one for a few days each and see what you like best, than become as proficient as you can with it, as it will be your sidekick for many days and nights.

Modal editing?

Editor classification goes way beyond modal vs screen-oriented vs line-oriented vs … but that is not our purpose. The idea here is to let you know what is modal editing and why should you (or not) use this way of doing things. Modal editors deal in modes when it comes to separating input and commands. So there is an input mode and a command mode, as opposed to “normal” editors, in which you input text then press Ctrl+S, for example, to save your text. These “normal” editors include everything we presented earlier except vi and relatives, which is a modal editor, and THE modal editor. At first sight this modal thing looks like just a way to make things harder, especially for the newbie. All I recommend is, again, patience, and those few days with vim (a vi derivative, the one we’ll be talking about), and make your decision after you’ve tried them all. Many people believe that modal editing greatly improves efficiency and speed, with the cost of a steeper learning curve.

The editors

Part one: vim

I must admit I took quite a task upon myself: to give you a tour of vim in a few hundred words, when there are whole books written on the matter. Well, those books expect to have you up and running with vi(m) after reading, while my purpose is to leave you with a clue about vim when this article ends. So, let’s waste no time. vim, upon startup, if you do so with no arguments, starts in command mode. The first thing you’ll like to do is start editing text, so you will have to give your editor a command for going in insert mode. That command is ‘i’, which stands for insert, so now you can type your text. Or you can open a file with ‘:e’. Wanna go back to command mode? Press ‘Esc’. You will want to save your text after a while, and that is done in command mode. ‘:w’ is the equivalent of ‘Save…’, while ‘:sav’ is the equivalent of ‘Save As…’ and ‘:q’ equals ‘Quit’. The commands can be combined, so ‘:wq’ is ‘Save and quit’. If you need to quickly exit without saving, append a ‘!’ to ‘q’. Remember that in vim, insert mode is only for typing; all the other facilities are accessed in command mode.

Eventually you will want to move around inside your text. Make sure that you’re in command mode and start forgetting about the arrow keys for moving one character at a time. While on most Linux terminals it works, it cripples the efficiency vim offers, and that efficiency is obtained by keeping your hands on the home row. So j and k are down and up, respectively, while h and l are left and right. You are recommended you make a copy of some already written text and start practicing on it, while remembering that vim and its’ graphical equivalent, gvim, offers the undo facility via the ‘u’ key (in command mode, obviously). But BSD vi (also known as nvi), which is the closest to the original vi that’s still maintained, doesn’t have a undo key, so better be careful.

After a while you’ll want to move word by word, so things will go faster, and by now you probably got a glimpse of the efficiency of vim. Not to mention its’ speed and size compared to other editors. If you want to move one word forward, the key is ‘w’ (word). If you want to move one word back, use ‘b'(back). It’s better if you learn by mnemonics, as you will learn faster, and you get to see how the apparent cryptic commands of vim are in fact shorthand for logically-worded instructions. Want to move one page up/down? No problem, use Ctr+d/u (down/up). Want to go to the beginning/end of the line? Easy, use ‘0’ (zero) and ‘$’. Indeed it’s a flood of letters and symbols to learn, but once you get a grip, no one will stop you.

You can use numbers to operate on certain parts of your text. Let’s say you get an error from your compiler that says there’s an error on line 8. You type ‘8G’ and there you are. That’s a capital ‘g’ and it, of course, stands for “go”. Yet another simple to remember command learned. Wanna go to the first line? Type ‘gg’; should you need the opposite, type ‘G’. If you want to move three words forward, just type ‘3w’. We can easily see that one can combine certain logically-close commands to improve their efficiency even more. Other tips from the “moving around” category include: ‘^’ to move to the first non-blank in the line, ‘(‘ and ‘)’ to move forth and back between sentences, ‘{‘ and ‘}’ for the same, but for paragraphs, ‘H’, ‘M’, ‘L’ to move to the upper, middle or lower side of the screen or 10Ctrl+B – move ten pages up.

Conclusion

Maybe this article seemed like some kind of slow-starting crash course in the editors’ world. Actually, it is, but we recommend you practice and re-practice, read and re-read the vim part and you will have a clue about it afterwards, which is what we wanted.