Text editors on Linux. Few things conjure up more images and memories of heated flame wars. Sure, you have the classic KDE vs. GNOME, and today’s Firefox vs. Chrome, but those battles pale in comparison to the mother of them all: the Emacs vs. vi wars. Who won? We all did.
Mighty warriors have fallen in those battles. Both camps were powerful, righteous, and just. Eventually no one really won the war. In fact, the war mostly disappeared in favor of more modern, immediate issues on the Linux front. But this does not mean the players disappeared. In fact, each and every warrior can still be found on the battlefield – along with new combatants. And the winners are the users who have a variety of much improved text editors.
In this Linuxables series I am going to introduce you to some of those tools that no Linux administrator (or user) should be without. In this series I’ll help you find an editor that suits your needs and personality perfectly, or as close as possible. I will waver slightly from the classic list of combatants in favor of adding newer text editors into the mix. Specifically, I am going to introduce you to: Nano, vi, Gedit, and Kate. Each of these serves a similar purpose and each has a very different approach.
But, before we get into the muck and mire of the tools themselves, let’s first discuss why the text editor is even necessary… or is it?
Why a text editor?
For many applications in Linux the configurations are handled by plain text files. You’ve probably heard of the .conf file? Some examples are:
- samba.conf
- apache2.conf
- resolve.conf
These files are often referred to as “flat text files.” What this means is that they have no formatting… they are plain text and no more. Some might assume a standard Word Processor (such as OpenOffice.org) can be used to edit these files, but this should be avoided for very good reason.
Generally speaking, word processors add extra formatting to text that will make the .conf file unreadable by the application. When the configuration file is unreadable by the application, the application will not work. What makes this even more challenging is that some times this extra formatting is obfuscated from the user. So you won’t even know you’ve added extra formatting to your file. To avoid this, the text editor is always used for configuration files.
Console-based vs. GUI
You will find, in this series, two console-based and two GUI-based editors illustrated. What are the differences? Simple: Text-based editors (such as Nano and vi) have no graphical component. These editors can even be used from the console login (making them indispensable for GUI-less server installations). Without the added overhead of a GUI, console-based editors are extremely light-weight, making them ideal candidates for users who demand speed and nearly instant response. The downfall? With console-based editors you are going to have learn a variety of key combinations.
GUI editors, on the other hand (such as Gedit and Kate) do have a GUI component which adds features that make desktop-centric users happy. The downfall of GUI-based editors? You must have a graphical desktop installed to use them. The pros for GUI-based editors? Ease of use. These tools work very similarly to standard word processors, so any user will be comfortable using these tools. The downfall? GUI-less servers need not apply. The added “weight” of the GUI also makes using them remotely more challenging than console-based editors.
The verdict?
That, of course, is yours to decide. In the upcoming series you will see these four editors up close and personal. By the end of the series, you will have a good idea which editor is best for your needs. But know this, whether you are a Linux administrator or a Linux end-user, eventually you will need a text editor and you will want to make sure you use the text editor best suited to your needs, ability, and style.