Evergreen

Evergreen

Evergreen started as a project to reimplement Rob Pike's Acme editor in Java, for use on Unix and Windows instead of Plan 9. In the decade since then, it's evolved in directions that help it deal with large codebases, and multiple projects/branches at once. Remaining similarities include the tiled windows and the Unix-like reliance on external programs rather than reinventing every wheel. The major philosophical differences include strong support for keyboard-based editing, language-specific functionality, and native platform UI conventions.

There are also two new guiding principles: accept regular expressions, output diffs.

Features

• Ubiquitous Regular Expressions - Programmers know regular expressions, and yet their graphical tools don't use make much use of them. Evergreen does. Anywhere it's asking you to type something, it's probably expecting a regular expression: full Perl/Java regular expressions in find, in find/replace, in find in files (as you'd expect), but also in the open dialog full details.

• Open Files Quicker - Evergreen indexes your project, so you don't have to remember where files are. Or what case your co-worker used ("Hyperlink" or "HyperLink"?). Just type a substring or regular expression that matches what you want full details. Evergreen updates a list of the matching files as you type (like iTunes):

  

• Find in Files - You can also search for files to open based on their content full details. Evergreen shows a tree of matches, representing the directory hierarchy. Files containing definitions are marked as such. Searching is done in parallel to take advantage of modern multi-core machines. Search results are automatically updated if anything changes:

  

• Find - You have a fast computer, yet the 'find' function in other editors doesn't take full advantage of that fact. Evergreen, like less(1), highlights all the matches, whether you search with C-F or clicked on a match in the "Find in Files" dialog. Better still, Evergreen highlights all the matches as you type, so you know when you've typed enough (or too much, if you suddenly see there are no matches). Evergreen also lets you move backwards as easily as forwards through the matches: just use C-D to move backwards and C-G to move forwards, both conveniently placed around C-F, which defaults to searching for the currently-selected word. All of this comes together for fluid one-handed searching full details. Finally, Evergreen uses marks next to the scroll bar to give you contextual information about how many matches there are, and how they're clustered. You can click on a mark to skip a large clump of uninteresting matches, if you wish:

  

• Spelling Checking for Source Code - Not only does Evergreen check your spelling as you type, it understands CamelCase words aren't single-word spelling mistakes but compounds of correctly spelled words. In this example, the identifiers have been checked too:

  

• Exuberant Ctags Support - Evergreen uses Exuberant Ctags (if installed) to understand the structure of your file full details. The symbols in the current file are shown as a tree preserving their hierarchy. You can click on an item in the tree to go to the corresponding part of the file. Conversely, as you edit, the item in the tree corresponding to the current caret position is always highlighted.

• Bug Database Links - References to bugs in your (or others') bug databases are automatically recognized and turned into hyperlinks:

• Find/Replace - Find/replace functionality in other editors has a habit of being awkward in use. How much better to be able to see all the changes at once, with the results of the substitutions? Hovering over a match shows the captured groups in a tool tip, so you can check your capturing is as you intended full details.

  

  (This is the obvious exception to the "output diffs" rule.)

• Workspaces - You can work on multiple projects at once, with each "workspace" getting its own tab in the overall UI full details.

  Workspaces are important. You probably want one for each project you're working on; if you're looking for "project" or "session" functionality, this is it.

  Each workspace's files will be indexed full details.

  Your workspace configuration (including which files you're editing) is automatically saved when you quit and restored when you restart Evergreen.

• Auto-Indent - Evergreen will automatically help you format your code in K&R, Linux kernel, or Sun's Java style full details. If you want to manually break long lines or use an indenting style too far removed from these, you're likely to face difficulties as it continues to try to "correct" your style. Ken Arnold's thoughts on coding style explain why this is usually a counter-productive degree of freedom. What you gain from accepting Evergreen's style (which shouldn't be a problem for most programmers) is that Evergreen will do most of the formatting for you. Even correcting stuff you paste in.

• Watermarks - Each document has a watermark, used to show you if you're looking at a read-only file, or a file that has been updated on disk since it was last read in.

• Building - Evergreen defers to make(1) or ant(1) to actually build your project, and will search upward from the directory containing the focused file looking for a makefile full details.

• Patches - If you choose a potentially destructive action such as "Revert to Saved", you're shown a colored patch and given a chance to change your mind. (Not only that, it's a useful way to see how a machine-generated file is changing as you work on the generator. Just keep running the script and reverting to the latest version of the generated file.)

• "Compare Selection and Clipboard..." - Shows you a patch comparing the currently-selected text and the text on the clipboard. This is useful when you're looking at two seemingly duplicate chunks of code and want to know what, if any, differences there are between the two.

• Language awareness - Coloring and intelligent indentation of C++, Java, Perl, Ruby, and others.

• Custom text component - We gave up on JTextPane because of its poor performance, and we gave up on JTextArea because of its poor functionality. Unlike many other editors with their own text components, ours was explicitly designed to be useful elsewhere. It's interface is broadly similar to JTextArea so it's easy to use in your own programs if you get used to any of the great functionality.

Mailing List

Feel free to visit or join the evergreen-users group.

Building from Source

See SalmaHayek.

Authors

The original implementation (which was much more like Wily) was by Elliott Hughes.

Ed Porter wrote a fast bitmap font renderer because in those days, Java's font rendering was too slow to be usable.

Phil Norman wrote the PTextArea text component we now use.

Sébastien Pierre contributed the icon.

Martin Dorey keeps us running on Windows.