Getting started with this extensible GUI text editor.
jEdit is a cross-platform text editor written in Java. The current stable version at time of this writing is 4.3.2, and it's available at jedit.org. Besides the cross-platform capabilities, jEdit offers other features, such as a sophisticated plugin system, syntax highlighting for 130 languages, a built-in macro language and extensive encoding support. I wrote this article using jEdit, and I demonstrate some of its features here, especially some of the plugins I have found useful.
Before I start, jEdit is a GUI text editor of some heft. It is not a replacement for using vi on the command line to edit a configuration file on a remote server. It does serve well in handling many files simultaneously with visual feedback and with the benefits of a GUI interface. To put it another way, I use vi or jEdit depending on the need.
Installation is fairly easy; just go to the download page and grab the installer jar. Be sure to check out the compatibility link if you have a non-Sun (Oracle) or Apple version of Java. From personal experience, I have not had success running jEdit on gcj. Assuming you have a compatible version of Java, use the following to install:
java -jar jedit4.3.2install.jar
This launches an installer program that guides you through the process. For the sake of reference, jEdit keeps its configuration files, on Linux anyway, in ~/.jedit/. I mention this because I keep that directory synced between my laptop and my desktop machines. As a result, I have a consistent working environment between the two.
At its heart, jEdit is a just a text editor, although it's a text editor with a lot of options. You can make these options global or apply them on a per-buffer basis. You can reach the options via the Utilities menu item. The global options stick between editing sessions, but the buffer options do not, unless you use the buffer-local method. This consists of embedding colon-separated hints to jEdit in the file. jEdit checks the first or last ten lines for these hints. As an example, to specify an indentation of 2, use spaces for tabs and “hard” wrap, the embedded hints would be:
jEdit checks anywhere in those lines, so you can place the hints behind comment symbols.
Also note that jEdit supports mode-specific settings, where a mode is a file type, such as Python (*.py), C (*.c), HTML (*.html) and so on. The various modes come with default settings, but they can be overridden. One of the key benefits is that the mode system pulls in file-type-specific syntax highlighting. Other options are available for the editor's layout. As you can see in the screenshots for this article, I tend to run jEdit with two buffers open, split vertically and with line-numbering enabled. The ability to look at the beginning and end of file at the same time, especially source code, is invaluable.
You can use jEdit in a great number of ways. Watching me enter text, although it has its moments, is not terribly inspiring. So to keep things interesting, here I demonstrate some of the plugins I have found useful. Plugins are code that scratches an itch. The base jEdit program does a lot, but it does not cover the universe that is text editing, or other chores for that matter.
jEdit has a macro system (not covered in this article), so you can whip up your own solutions to problems or scope out the plugins available and not re-invent the wheel. So, before getting into the plugins themselves, here's an overlook at the plugin system itself. They can be found at plugins.jedit.org or via the Plugins item on the menu bar. Click on the Plugin Manager item and then the Install tab for a list of available plugins. Clicking on an item shows a description at the bottom of the page. Check the box of any plugin(s) you want to install, and then click Install. If the plugin has dependencies, they also will be installed.
So, where to start with the plugins? Let's go from less-involved to more-involved, beginning with one suggested to me by a member of the Bellingham Linux User Group: WhiteSpace. It does what it says—tracks whitespace. I have it set up to show trailing whitespace and, additionally, to eliminate any such whitespace when I save. I also have it show tabs and modify them according to my jEdit soft tab setting. This setting, when enabled, converts tabs into a defined number of spaces. WhiteSpace uses the setting to convert preexisting tabs into spaces or vice versa. All of the above helps when I work in Python code, keeping that pesky whitespace in order. This also is valuable when writing for Linux Journal, which requires that writers use spaces not tabs. See Figure 1 for WhiteSpace in action on a Python file. From the screenshot, you can see one way to set it up. The other way is to go to Plugins→Plugin Options→WhiteSpace. This is how most of the plugins work, although you will find there often are differences in options available between the two locations.
Another plugin I use quite often is JDiff. As the name implies, it shows the diff between files. Of course, you could use the command line to do the same thing. The benefit of the plugin is the graphical presentation it provides. Figure 2 shows the dual-diff mode using this article as the files. From here, you can create a diff output. You also can walk through the diffs and apply them from one side to another.
The JDiff plugin has a dockable component that allows you to drill down into the lines of the files for differences (Figure 3). In the dual-diff screenshot (Figure 2), you can see another plugin at work, VoxSpell. The underlining is the spell-checker at work. If you look at the file, you can see that plugin/plugins go from being underlined to not underlined. I right-clicked on the words and added them to the dictionary as acceptable, at least for the purposes of this article. Note that VoxSpell has a dependency on the Spell Check plugin. It also uses quite a bit of memory, so that may be an issue.
Next is a chicken-and-egg problem. I ran across a reference to the SQL plugin for jEdit. In the course of installing it, I found it had a dependency on the Project Viewer plugin, which meant I had to learn how to use Project Viewer in order to use the SQL plugin. It turns out that was a good thing. In fact, this article was written using Project Viewer. First, I will cover the SQL plugin and later expand on the Project Viewer plugin.
SQL allows you to work with SQL databases from within the editor. Setting things up to use the plugin is a two-step process. First, you need to do the general setup in the SQL options dialog. Go to the menu, then Plugins→Plugins Options→SQL. Go to the JDBC page and use the Add Element button to indicate the path(s) to the JDBC drivers you want to make known to the program. At the time of this writing, SQL can work with Oracle, MySQL, PostgreSQL, Firebird, DB2, Progress, MS SQL Server 2000, Sybase and Teradata, assuming you have the requisite JDBC drivers. This previous step “registers” the database so it can be used in the next step.
The next step is to configure a specific database (or maybe more than one) with a project. This is where Project Viewer comes in. You use it to create the project (more detail on that later). For now, I will use the project that is this article. From the project pane, right-click on the project name and select properties. This will lead to a series of dialogs that allow you to fill in the needed information (Figure 4). In this case, I am using the Pagila demo database for Postgres. From a jEdit buffer, you now have access to the database (Figure 5). There is quite a bit going on there, so let's take it a step at a time.
Just above the buffers is the SQL toolbar. First, above the left buffer is a Database: drop-down list with the previously configured database selected. To the right of that are four buttons: the first is Execute selection, the second is Execute buffer, the third is Load object, and the last is Repeat last query. To the right of the last button is the Preprocessors drop-down. For this example, I am using the Variable substitution preprocessor. This can be seen in the “actor_id > ?” expression in the SQL statement in the right buffer. (As a side note, notice the SQL syntax highlighting prompted by the use of the *.sql extension.) To continue, I have selected the statement I want to run and then clicked the Execute selection button. Because I have variable substitution in force, an input box was presented (not shown) for me to enter the value for actor_id, in this case 35. The result is presented in a separate window. From the result set, it is possible to save the data as CSV or tab format or as INSERT statements. You also can show/hide columns. Additionally, it's possible to run multiple statements at once (Figure 6). This is a somewhat contrived example, but it does show what's possible. The previous feature allows me to create database DDL files and run them from within the editor.
The last feature is SqlVFS (Sql Virtual File System). This allows you to browse the selected database as a filesystem. To get there, go to File→Open→Commands→Plugins→Show databases. Figure 7 shows what you get. Note that although Data says 0 bytes, double-clicking on it gives a result set from the table.
Project Viewer is a plugin to make handling a group of related files (a project) easier. For demonstration purposes, I'm using the files that make up this article. Project Viewer creates a docked button below the menu bar. Click it, and a drop-down appears with All Projects listed. Click this, and a window opens. Right-click on All Projects, and select Add project, and you get another window (Figure 8) to enter the required information. Click OK to create the project. Project Viewer then takes you to that project and puts up a prompt about importing files into the project. By default, it imports everything below the root directory.
At this point, the group of files is bound together as a project. The benefit is that Project Viewer keeps track of their state and allows you to return to that state at a later time. Note that it's possible to add other directories/files to the project later. Simply right-click on the project name, select Add files and navigate to the desired location(s). You can add new files from the existing directory in two ways: one is manual and the other automatic. The manual option is to right-click the project name and select Re-import files. The automatic option is to open the project name context menu, select Properties→Auto Reimport and enable it with a time parameter. Figure 9 shows the visual indicators as to the status of files, where underlining represents open files and color indicates type of files.
One really handy feature is the Compact View of a project. This is enabled in the General Options of the Project Viewer plugin options. It presents a flattened view of a directory structure. This article does not really have the directory depth to illustrate the benefit, so take a look at a screenshot from another project (Figure 10). Each line takes you directly to a directory. Also of note is the Working Files tab in the project window. This groups all your current open files together, which is handy in a large project.
Some other features include archiving the project files in a JAR file and searching in the project or project subdirectory files for a string. The ability to consolidate all of the files related to a project in a single interface is something I've come to appreciate even more as time passes. Walking through a Project Viewer directory tree renaming/moving/deleting files while looking at the actual files is priceless.
What I have presented above barely scratches the surface of what is possible with jEdit. It has a macro facility that I have not even started to explore. The most important part of jEdit, to me, is that it lets me get work done without getting in my way. Furthermore, it makes that work easier, and I hope you find it useful also.