NJEdit is a WYSIWYM editor of sorts that I created in order to draft the manuscript for Closure: The Definitive Guide. I named it NJEdit because it was implemented in the spirit of the so-called New Jersey approach. Rather than implement a general-purpose word processing application (of which there are many), NJEdit supports only the formatting options that I needed to produce my manuscript.
As the primary output of the editor is a representation of the document in Docbook XML that can be consumed by the production team at O'Reilly (which is ultimately transformed into a version that is suitable for publication to print), NJEdit constrains the set of formatting options to those that can be realized in DocBook. More specifically, it only supports the set of features of DocBook that I needed to use. For example, as I never encountered the need for boldface text while writing my book, I never added such a feature to NJEdit.
Originally, NJEdit was implemented as a Firefox extension (using Chickenfoot, of course) so that it had the security permissions to include code snippets from source code on local disk. (This was done to ensure that my code samples and my manuscript would be in sync.) By using Firefox as my platform, I was able to leverage all of my knowledge of JavaScript/HTML/CSS to implement NJEdit while I was simultaneously inhibited by the quirks of content-editable HTML elements. Despite these tradeoffs, I was able to construct an editor with the following features:
- In NJEdit, a document is a sequence of paragraphs where each paragraph is a member
from a fixed set of types: prose, code sample, heading (three levels),
list item, or XML blob (this last type was my "escape hatch" that prevented
me from having to support every little feature of DocBook in NJEdit).
Changing the type of the paragraph is achieved by hitting
ctrl+enterwhile the cursor is in the paragraph. This is considerably easier than fiddling with the mouse to highlight the appropriate section and then choosing the formatting style from a menu. Further, it also guarantees that all paragraphs of the same type are formatted in exactly the same way. - Because Firefox was used as the platform for the NJEdit, each paragraph type could be rendered using the appropriate HTML and CSS. Therefore, unlike a view of the raw Docbook XML in a text editor, the view of the document in NJEdit had some resemblance to what the final product would look like. The other way to gain insight to how the final product would look was to upload the Docbook XML to O'Reilly which would produce a PDF of what the book would look like in print, but that process was far too slow to be done frequently.
- Text that should appear in the constant width font used for code samples
is delimited by backticks, so instead of typing
<code>functionCall()</code>as you would in an ordinary text editor, you would simply type`functionCall()`. In the course of producing a 500+ page manuscript of technical writing, this becomes a huge savings, as a document littered with<code>markup would be a distraction while both reading and writing. - Hitting
ctrl+Ssaves the current version of the HTML to Google Docs. By being more lightweight than a commit to O'Reilly's Subversion repository, this greatly reduced the cost of saving intermediate versions. Further, Google Docs has a decent UI that understands HTML when comparing versions of a document. By comparison, I do not find the output ofdiffto be an effective visualization of what has changed.
Although NJEdit was implemented from a "works for me" perspective, I decided to
port it to a webapp as others may find it useful.
Further, I have open-sourced the code and made it available on
Google Code.
Personally, I plan to continue to use NJEdit to write technical articles such as
"Inheritance Patterns in JavaScript", but if others find it useful and want
to contribute, then I will happily accept patches.
