Previous: Getting Started, Up: Introduction
A development environment should support three activities: code spelunking, interaction, and customization. Emacs as an environment for developing Emacs Lisp thoroughly supports all of them: It has commands to visit individual functions' code and documentation, commands to evaluate or step through expressions, and an architecture that encourages customization in Emacs Lisp. As an environment for Perl, however, it is lacking: there is limited interactivity with the Perl debugger, and reasonable documentation browsing, but no support for navigating, editing, and re-evaluating code. Sepia attempts to remedy the situation.
Modern IDEs also support these three activities, but do so awkwardly. Rather than having functions to visit definitions (find-function) and search for functions (apropos), they clutter the screen with class and file trees. Rather than supporting interactive evaluation of small pieces of code, they perform background semantic checking on whole projects and highlight errors. Rather than allowing minor customizations to grow organically into features, they support limited configuration files and baroque plug-in APIs. Sepia tries to adhere to the apparent Emacs philosophy that rich semantic information should be unobtrusive, and that the best way to build working code is to start by experimenting with small pieces.
Language support packages for Emacs vary widely in the degree to which they make use of or replace existing Emacs features. Minimal modes provide keyword-based syntax highlighting and an unadorned comint buffer as an interpreter. Others provide their own specialized equivalents of comint, eldoc, completion, and other Emacs features. Sepia takes a third approach by trying to do as much as possible with existing Emacs features, even when they are not optimal for Perl. It uses comint to communicate with the subprocess, eldoc to display documentation, and grep to list source locations.
This approach has three advantages: First, it maximizes the number of features that can be supported with limited development time. Second, it respects users' settings. A seasoned Emacs user may have changed hundreds of settings, so a mode that reimplements features will have to support equivalent settings, and will force the user to re-specify them. Finally, this approach respects decades of development spent, as Neal Stephenson put it, “focused with maniacal intensity on the deceptively simple-seeming problem of editing text.” Many non-obvious choices go into making a polished interface, and while a reimplementation gets rid of accumulated cruft, it must rediscover these hidden trade-offs.
Anyways, I hope you enjoy using Sepia. Its development style is strange for someone used Perl's typical mix of one-liners and edit-save-run, but once you are accustomed to it, you may find it very effective.