In the 1990s, there was this idea called WYSIWYG (What You See Is What You Get).
This idea was largely centered in the Desktop Publishing world; in that context, the "what you get" is the output on physical paper, and the "what you see" is the input document on the computer screen as you are composing it.
The idea was simple though: when a user performs an action, they want to see the effect that the action has immediately, without a manual processing step required to generate the effect.
Wikipedia has some hilarious text, referring to the pre-WYSIWYG world as though it is dead and gone:
“Before the adoption of WYSIWYG techniques, text appeared in editors using the system standard typeface and style with little indication of layout (margins, spacing etc.). Users were required to enter special non-printing control codes (now referred to as markup code tags) to indicate that some text should be in boldface, italics, or a different typeface or size.”
But even to enter that last bit of light styling - a link and a quotation - I needed to visit a reference page for a markup language, and render ("preview") the text several times to see what it would actually look like to a consumer.
Why are these antediluvian techniques still so popular?
Particularly, I wonder why these techniques are so popular within the context of the lingua franca of the web, HTML.
But, what if you want to write an HTML document, let's say for the purposes of documenting your software? How would you just write (or edit) a plain old HTML document and save it to your disk?
When we created Lore (in around 2001), the thinking went something like this: right now we all have either graphical word processors with proprietary formats, or programmers' text editors that can tediously churn out angle brackets, but surely within 5 years HTML will have killed every other format and everyone will have easy access to a GUI editor that can edit HTML files so Twisted's team of technical writers (ha ha) will not need to learn any tedious or arcane markup, and we can all use standard tools.
At the time, Mozilla Composer was a clear indication that we were on the right track: in Mozilla, you could hit "edit web page" on any page on the web, and save your results to a local disk file, as well as open up HTML documents via file:/// URLs for editing. It seemed as though a polished, consumer-friendly version was surely only a year or two away.
Of course, as I would learn in later years, "a year or two away" is software jargon for "never".
Oddly though, the dream of the 90s never completely died. You can still get a fairly modern, up-to-date version of Mozilla Composer via the SeaMonkey project - pronounced "dead" with the advent of Firefox, SeaMonkey continues to prove that old adage, "that is not dead which can eternal lie".
You can also get a stand-alone, albeit somewhat more cluttered, instantiation of this code from the BlueGriffon project.
Both of these are still somewhat problematic for use in software projects though, since they both automatically pretty-print and re-flow the underlying HTML source, which makes it difficult to view a diff or resolve a merge conflict with any accuracy.
Version control tools all still operate at the level of line additions and deletions, and don't accommodate data with structures that don't map neatly to those boundaries.
Thus, one of our atavistic tendencies as software developers reinforces another: because diff and patch tools all operate at the level of line additions and deletions, we can't use tools which manipulate graph structures but don't contort themselves to preserve artificial formatting constraints to avoid producing giant, incomprehensible deltas.