Today I thought I would steer away from hard-core high-performance computing (HPC) topics – but not too far – because I want to discuss options for a key critical HPC tool: the editor.

The editor can be one of the most important tools, if not the most important tool, for administrators of HPC systems. It's also the tool that will generate a tremendous amount of – shall we say – discussion, possibly resulting in the exchange of insults and general loathing of our fellow human beings. Despite the risks, discussing editors is a useful, interesting, and worthwhile exercise.

I argue that systems administration in general, and HPC in particular, needs a command-line editor, because it can be used even if X Windows isn't working or isn't installed on the servers. Knowing how to use SSH and a command-line editor has saved my admin bacon on several occasions. You don't have to be an expert, but you do need to know enough commands to edit files and be comfortable with the editor.

After knowing and being comfortable with a command-line editor – enough that you can SSH to a server and edit a configuration file – you can either choose to learn a second graphical user interface (GUI) editor or not. A GUI editor can be advantageous if you are a visual person (like me), but it's not a requirement. Personally, I use a GUI editor or two when writing code and writing documents.

Assumptions and Ground Rules

Before jumping into editor options, I want to put down the assumptions I'm using in my selection of what editors to write about. The starting assumptions are:

• The focus is on open source editors .
• The desire is for multiplatform editors, although this isn't a hard and fast rule, but at a minimum it has to run on Linux.
• The focus is on text editors and Integrated Development Environments (IDEs). IDEs are a different beast with different feature sets; however, a few editors I will mention can function as a very basic IDE.
• My goal is to present editor options and list some of their more significant features. I will not be rating or judging the editors. I might also miss some features of the editors – please don't rely on this article for information to make a decision – try out the editors that interest you.
• I will likely not include editors that other people use and recommend. I'd love to hear more about them, so please contact me.

I've divided the editors into two sections: command-line (CLI) editors and graphical user interface (GUI) editors. Let the mayhem begin!

Command-Line Editor Options

Eons ago, when I started with *nix, CLI editors were all we had, so you learned them very quickly. Now that X is so popular, many people don't bother with CLI tools. Therefore, not many open source CLI editors are available today. However, I promise you that learning a CLI editor for systems administration, particularly in HPC, will help you at some point in your career (and they will carry you around the data center on their shoulders afterward).

Command-line editors can work in basic terminals and don't require X Windows or any type of window manager or similar tool. Command-line editors allow you to edit files on a server that doesn't have X running or installed. This can include SSH-ing into a remote server, using a parallel shell tool to run commands on multiple nodes, or both scenarios. Considering that, many times, compute nodes don't have X installed, being able to triage, debug, and fix a compute node with a simple CLI editor is very valuable.

Below are four CLI editors that are commonly available with most Linux distributions. There are a couple of others, but they aren't very common and don't seem to have as many users. Therefore, it is unlikely that they will be installed on servers. I'm going to start with probably the oldest CLI editor, but one that serves as the foundation for another editor.

ex

Ex was written by Bill Joy in 1976 as something of a replacement for the original *nix editor named ed (ed was developed in 1969). Bill Joy modified a development of ed, named em, to create ex.

Ex is a CLI editor, in that it operates on individual lines or groups of lines that you have to specify at the command line. In today's *nix world, it is a “personality” of vi and provides some functionality that vi cannot, so if you have learned vi, you already know some ex commands.

You can start ex on the command line in most Linux distributions by simply typing ex. This is typically the CLI personality of vi. One feature that ex originated is the substitution command, which is what you use in vi to make a substitution on a specific line, set of lines, or the entire tile. For example, you can run the command:

: s/XXX/YYY/g

This commands substitutes the string XXX for the string YYY, normally for the current line. However, in this case, it does it for the entire file because of the g option at the end of the command.

The slash (/) is just a delimiter to separate XXX and YYY (the string you are replacing and the new string), but you can use other delimiters if you like – you just have to use them consistently (i.e., they have to be the same). This is especially useful if you want to substitute a string that includes the slash. I tend to use + as my delimiter when a slash is involved.

I wouldn't say that ex is the ideal CLI editor, but knowing a bit of ex in conjunction with vi can be very useful.

vi

Bill Joy designed vi to be the "visual mode" for the ex editor. It was part of the original ex via the visual command but wasn't its own binary until about 1979. Vi is a screen-oriented editor, in contrast to the line orientation of ex.

In general, vi is a modal editor. It operates in a particular "mode" such as Insert mode or Normal mode. When in Insert mode, for the most part, the keystrokes are interpreted to be text that is inserted into the file. In Normal mode, the keystrokes are taken to be commands. Knowing which mode you are in is one of the earliest aspects of vi that need to be mastered.

Figure 1 shows vi running running in Normal mode on my Linux CentOS 6.8 desktop. At the bottom of the screen is the colon (:) prompt for the vi commands.

Figure 1: Vi 7.4.629 on CentOS 6.8.

The rivalry between vi and the next CLI editor, Emacs, is HUGE.

Emacs

Emacs is arguably the “Swiss army knife” of editors. It is extremely extensible and customizable, including the extensive use of macros. It has more than 2,000 commands built-in to the tool and includes a dialect of Lisp named Emacs Lisp that allows users to write new commands. Development started in the 1970s at the MIT Computer Science and Artificial Intelligence Laboratory and continues to this day. Richard Stallman started work on GNU Emacs in 1984. Emacs has had a number of versions over the years and has been forked several times.

One of the features that attracts people to Emacs is its ability to work with other applications (i.e., very *nix-like). For example, from within Emacs, users can read their email, compile code (i.e., similar to an IDE), use a calculator, interact with a spreadsheet, check newsfeeds (RSS), or browse the web. Essentially, Emacs becomes the center of one's working environment. In fact, some users only use Emacs because it can reach so many other tools. What you use Emacs for is up to you, and you are not forced to use it for everything.

Emacs can split the main editing window into separate "panes" (Figure 2). It has had this ability before GUIs were available. Each pane has a status bar at the bottom. The classic example of splitting the main window into panes is to have one pane on top for editing code and one pane at the bottom for compiling and testing the code. This allows Emacs to be used as an IDE. In CentOS 6.8, the command emacs starts the GUI version.

Figure 2: Emacs 23.1 on CentOS 6.8.

Nano

Nano is designed to be a simple editor that can be used in a console. It is based on Pico, which is part of the Pine email client, but it has had some functionality and new features added, such as regular expressions.

In the past couple of years I have seen much more interest in Nano (Figure 3), partly, I believe, because Nano has the command help at the bottom of the screen at all times, which, if you don't use Nano very often, can be very, well, helpful. Another reason it might be so popular is because a new influx of users who have no preconceived notions of a *nix editor such as vi or Emacs have adopted the easiest CLI editor they could find.

Nano was released in 1999 as free software. It joined the GNU Project in 2001. Development under this umbrella proceeded for several years until June 2016 when the current principal developer and the other active members of the nano project decided to leave the GNU project, leaving GNU nano intact but taking active development outside of GNU (a fork). This move was taken because of their objections over the Free Software Foundation's copyright assignment policy.

Figure 3: Nano 2.0.9 on CentOS 6.8.

JOE

The last CLI editor I want to present is JOE, which stands for “Joe’s Own Editor,” available under the GPL license. JOE was started in 1991 when applications such as WordStar and Turbo C were very popular. JOE’s keystrokes are similar to those in these two programs. JOE can emulate Emacs and has a link to a binary named jmacs. It has similar emulations for Pico (jpico) and WordStar (jstar).

According to the Wikipedia article for JOE (Figure 4), it was included in many early Linux distributions, so it has a pretty reasonable user base. Its development has bumped along, with the latest stable release in September 2015. One nice feature in JOE is that the shortcut key for help is always shown on the screen.

Figure 4: JOE 3.7-4 on CentOS 6.8.

GUI Editors

In my opinion, GUI-based editors are a “nice to have” tool in the sys admin’s toolbox; I use one every day. First and foremost, admins should know a CLI editor in case they need to log in to a system on which X is not running or it is not installed. To be honest, though, the frequency of these situations is much lower than it used to be, so knowing a GUI editor for developing code, processing and reading logs, or writing articles or manuals is a very useful tool.

In this section, I want to mention a few GUI editors that seem to be popular. I chose open source editors that I have heard about and have, for the most part, experimented with in some fashion. It’s definitely not an exhaustive list, and I don’t contrast features, but I do try to provide some personal insight into them.

At this time, I am not considering IDEs, which can also build and execute an application from within the editing environment. Text editors strictly allow you to edit text in documents. Although editors and IDEs often overlap, the focus here is on editors.

Atom

Atom was designed by GitHub Inc. The cross-platform editor is written in CoffeeScript and Less, and it’s embedded Git controls lend a huge appeal to developers. Atom has a large range of default plugins written in Node.js for many languages.

Atom (Figure 5) has become a very popular editor because it's very hackable and it has built-in GitHub controls and Github is where everyone stores their code now. It is also cross-platform since it uses web tools such CoffeeScript, Less, and Node.js.

Figure 5: Atom on Windows 10.

If you write a fair amount of code and are looking for a good modern editor, take a look at Atom.

Editra

Editra is a multiplatform editor written in Python using wxWindows (renamed wxWidgets). The first version was released in 2007, and it is still under development. The current version has not yet reached 1.0, yet it has a great deal of promise and being written in Python greatly improves the cross-platform capability.

Even though Editra is in development, it has a large number of features you would expect from a more mature editor, including:

• Syntax highlighting for more than 60 languages
• Auto-complete (Python, C, XML)
• Auto-indent
• Column edit mode (sort of rare in editors, but very useful)
• Customizable interface
• Editing of remote files using the FTPEdit plugin
• Integrated Python shell (PyShell plugin)
• vi keybinding support
• Zoom
• Code folding

Figure 6 shows Editra running on a Windows 10 laptop (testing the multiplatform capability).

Figure 6: Editra 0.7.20 on Windows 10.

Geany

Geany is my exceptions to the “no IDE” rule, because it can also be used as a simple editor. It is written with Gtk+ using the Scintilla editor component that is also used in the Windows version of Notepad++.

Figure 7: Geany 1.27 on Windows 10.

At the bottom of Figure 7, you can see a feedback area used during compile time. You can minimize this section to give yourself a larger editor window. Geany has many of the features of a classic text editor:

• Syntax highlighting for 64 languages
• Code folding
• Auto-completion
• Project management
• Multiplatform

Geany is easy to learn, so you can be productive immediately, and if you need an IDE, you can keep using the same tool.

gedit

A couple of years ago I had a personal editor crisis at about the same time as Joe Landman. We had both used NEdit for many years. However, it was getting a little old, in some cases crashing on certain distributions, so I started looking at editor options, many of which you are reading about in this article. The editor on which I decided for most of my work is gedit.

Gedit is the default text editor for Gnome and is considered part of the Gnome Core Applications. This multiplatform editor is available for Linux, Microsoft Windows, and Mac OS X. It has the classic editor features, such as line numbering (absolute necessary in my opinion), bracket matching, text wrapping, syntax highlighting, automatic indentation, and automatic file backup. It performs syntax highlighting with the help of extension files.

I started using gedit on Windows with version 2.30 (Figure 8) and with about the same version on CentOS 6.x.

Figure 8: Gedit 2.30 on Windows 10.

The current version 3.20 (Figure 9) of gedit has a new, cleaner interface that works with newer desktop interfaces such as Unity.

Figure 9: gedit 3.20 on Windows 10.

jEdit

One of my pet peeves about GUI text editors is that they are rarely able to handle column manipulation – that is, the ability to cut/copy/paste text in a column fashion. For many years I used NEdit, which has this ability, and I used it frequently. However, NEdit had not been updated in a while, and I had problems with it crashing, so I started looking for new editor. The first feature I looked for was the ability to perform column manipulation. jEdit was the first, but not the only, editor I found that could do this.

jEdit is written in Java, so it runs on any OS with Java support. It has a large number of features desired in a text editor, including:

• Syntax highlighting for more than 200 languages
• Split-screen mode
• Code folding
• Markers
• Customizable
• Macros
• >150 plugins
• Column manipulation (cut/copy/paste)

Plugins allow jEdit to behave as a lightweight IDE. Figure 10 illustrates the interface.

Figure 10: jEdit 1.7.0 on Windows 10.

JuffEd

Perhaps a lesser known is JuffEd (Figure 11), which is nevertheless a powerful cross-platform text editor. As with two other editors in this review, JuffEd uses Scintilla for the editor component.

Figure 11: JuffEd 0.8.1 on Windows 10.

JuffEd has a very large feature set that comparable to the most advanced editors:

• Plugins for syntax highlighting for 20+ languages
• Code folding
• Braces matching
• Cross-platform
• Line numbers
• Markers
• Multilingual support

Take a look at JuffEd – it is pretty nifty.

Kate

Kate (KDE Advanced Text Editor) is part of the KDE Software Compilation and is considered the KDE text editor. It has been around a fairly long time starting with KDE 2.2 in 2001.

Kate has many of the features of a classic editor, including syntax highlighting (based on file extensions), code folding, layouts that can be customized, regular expression support, and more. If you haven't used code folding before, you should try it out; it can be a useful feature in long code files. You can take a section of code and "fold" it so that it is hidden from view. When you "unfold," the section of code becomes visible.

Kate (Figure 1) also allows you to split the screen so you can see two parts of the file at the same time (always a useful feature). On the left-hand side, Kate maintains a list of files that are being edited, so you can switch back and forth.

Figure 12: Kate 3.3.4 on CentOS 6.8 with KDE.

Leafpad

No one says that a GUI editor has to have lots of features. It can be very lightweight and simple, which is exactly the focus of Leafpad, the default editor for the LXDE environment and Xubuntu 11.10 and 12.04. If you have used Raspbian on a Raspberry Pi, you probably used Leafpad.

Leafpad (Figure 13), currently only runs on Linux. It is not feature rich because its focus is on ease of use, small size, and fast start-up. Its main features are:

• Codeset option
• Unlimited undo/redo
• Auto-/multiline indentation
• Drag and drop
• Printing
• Line numbering

I started using Leafpad on Raspbian with a Raspberry Pi 2, and I found it to be very useful and quite fast. I've been using it on my Linux laptop as well. Below is a screen shot of the editor on my Linux desktop.

Figure 13: Leafpad 0.8.18.1 on CentOS 6.8.

NEdit

The first GUI editor I used was NEdit (Nirvana Editor) on SGI workstations running IRIX. It was originally developed at Fermilab, but the version today on Linux was developed as an independent open source project with the GNU GPL license. NEdit was built using the Motif toolkit, which was very popular when it was released.

I used NEdit on Linux for many years to write a great deal of both code and text. According to the Wikipedia article, development of NEdit stopped in 2010. With few updates since, the last release was version 5.6 in December 2014, which was 10 years after the release of the previous version.

NEdit (Figure 14) comes with many features, including bracket matching, syntax highlighting, line numbering (basically mandatory for a text editor), a very good search and replace function with which you can use regular expressions, macros, block selection of text (i.e. specified rows and columns), and my personal favorite, column cut/copy/paste capability. If you look around the web a bit, you will find lots of people who recommend it highly, but be aware that NEdit still relies on Motif, which is slowly giving way to more modern toolkits.

Below is an image captured from my CentOS 6.8 desktop.

Figure 14: NEdit on CentOS 6.8.

Notepad++ and Notepadqq

One of the most popular editors in the Windows world is Notepad++. As you can tell from the name, it is intended to be a much better version of Notepad, which has been very popular for editing code on Windows. Figure 14 is a screenshot from my Windows 10 system.
Notepad++ has split-screen editing, a tabbed document interface, a spell checker, syntax highlighting, code folding, brace matching, macros, and several other features common in editors. It supports a large number of languages for syntax highlighting, including Fortran (the true language of HPC kings), Matlab, Python, and Perl. People have been asking for Notepad++ on Linux for many years. The code is open source and uses the Scintilla editing component. However, it uses some pure Win32 and Standard Template Library (STL) functions, so it doesn't port easily to other platforms, although a few attempts have been made with without any real success.

A Linux editor that is similar to Notepad++ is Notepadqq (Figure 15), which is a pretty close Notepad++ work-alike for Linux. It includes syntax highlighting, code folding, support for many languages (>100), and extensions written in Node.js (JavaScript).

Figure 15: Notepadqq on Windows 10.

SciTE

The SciTE editor is also based on the Scintilla editor component; therefore, it is somewhat similar to Geany and Notepad++. Designed to be simple and lightweight, SciTE (Figure 16) has a number of good features:

• Syntax highlighting (36 languages)
• Editing multiple files at the same time
• Selection of rectangular sections of text
• Code folding
• Scripting in Lua
• File export as plain text or PDF

Figure 16: SciTE 3.3.5 on CentOS 6.8.

SciTE has two windows. The top (or left) is for text editing and the bottom (or the right) is called the output window. You can minimize this window to maximize editor space.

Parting Words of Wisdom

The examples in this article are only a few of the possible choices you have for editing. However, I strongly recommend that you learn the basics of at least one CLI editor and at least one GUI editor, which I think are better for writing code and documents.

In the end, which editor or editors you use is a personal choice. It's good to try out new editors from time to time, but don't let anyone bully you into switching editors.

This blog represents my own view points and not those of my employer, Amazon Web Services.