Room 101

---

Gilad Bracha's blog. A place to be (re)educated in Newspeak

Originally published August 15th 2022

What You Want Is What You Get

Today I want to discuss text editors, specifically, rich text editors.  This post will focus on one particular issue in the design of such editors, the tension between two extremes, WYSIWYG (What You See Is What You Get) and markup.

WYSIWYG has the advantage of liveness. You have the final product directly in front of you at all times; every action you take is immediately reflected in it. It is concrete. Markup has all the benefit of using a language. You edit a description of a document, written in a markup language. That language allows you to define and use abstractions. You can compose sophisticated abstractions out of simpler ones. In some systems, you can even write metaprograms that manipulate markup programs, allowing you to analyze, transform or even synthesize documents.

My goal, as usual, is to have my cake and eat it too: in this case, combine the advantages of both of the above approaches.

Tangent: I was gratified to learn recently that this perspective on cake ownership and consumption has long been advocated by Alan Kay. It is indeed a very valuable approach to design issues, technical or otherwise.

First, a few more background observations.

• Markup naturally lends itself to a very important kind of abstraction: abstracting over presentation detail. This allows for keeping content and presentation separate. We see this in many places: the distinction between \it and \emph in LaTeX, or between CSS and HTML, or between Model and View in GUI.
• Markup does not necessarily impose such an abstraction however. The markup language's features can be presentation specific. Likewise, some tools allow you to edit a rendered document live, but take pains to formulate their interactive operations as semantic operations. Editing live documents in this way is often referred to by the acronym WYSIWYM (What You See Is What You Mean)

The acronym is a bit unfortunate, since it's hard to discern what it means.

• Even a pure WYSIWYG tool maintains a description of the document it creates as part of its internal data structures. WYSIWYM tools tend to use a markup language program as the definitive document description.

To combine, as much as possible, the strengths of markup and of live document editing, the editor's model, its sole source of truth, should be a markup program describing the document, and that model should be exposed to the user. This is the correct design for a rich text editor, independent of whether one embraces WYSIWYM or not.

Text editors that do not deal with rich text, i.e., poor text editors,  need not be concerned with markup, as there is nothing for markup to say; there is nothing but the text, as a certain French philosopher reputedly said.

Every edit should result in a modified markup program, which should be instantly processed to produce the rendered view the user sees. The user should have the option of seeing, and if they wish, editing, the markup program in a parallel view. Of course the two views should always be in sync: if you modify the markup, the change is immediately reflected in the rendered view, and vice versa.

Here is an example of what that looks like:

Above is an editor; it is running live inside this post. 

Caveat Emptor: It's just a prototype, be gentle. It's buggy and lacks many features, but many of these deficiencies can be overcome using the markup. That's another advantage of the architecture I'm advocating for here.

You can edit the rich text directly. To its left is a toggle; if you click on it, it will expand into a raw text editor showing HTML that defines the rich text shown on the right. You can edit that HTML and see the changes take effect immediately in the rendered document. You can also do the opposite: edit the rich text and see how the markup is updated to reflect that. 

Of course, a modern editor must not be limited to text, however well typeset. One has to be able to embed live widgets within it.  How shall we do that? Above the text is another toggle. It opens up a toolbar that provides more functionality. Open it, and type the string alertButton into the text above. Then select that string, and press the button marked Make it an Amplet  on the toolbar. You should now have a live button embedded in the text. Press it for an important message. This post was created in the same editor, and it includes live widgets. One is the editor above. Another is this button: 

. If you click on it, you'll see an object presenter on a document (documents are objects of course, just like everything else). The object presenter includes an editor of the same kind as above, with the same contents as this web page. However, unlike this page, the text is mutable. If you don't like what I've been saying, you can edit it as you wish.

Of course, this architecture isn't new. Some form of it has been around since the 1980s.

I have fond memories of Framemaker, which I used extensively in the late 90s and early 2000s. The specifications for the Java language and VM were written using it.

However, it's been uncommon to have it fully realized as a two view editor that's live in both directions and incorporates live widgets. Rarer still is the ability to write new widgets or modify existing ones live in the same editor, or modify the editor live from with itself.

If you want to know more about how this particular editor works, you can watch this 5 minute video, or this older, more detailed 15 minute one. Or just go to the Newspeak IDEs home screen and  explore the code:  




Of course, there are other important aspects of editor design. Editors should be totally scriptable, as I wrote in a

post some years ago.  I'd also argue the editor should be implemented in its own, self-hosting, scripting language. Moreover, all these principles apply beyond text editing. Ultimately, the editor, UI, IDE and operating system should all converge into a unified, coherent environment to serve humans.  We won't tackle all of that today; just remember that there is a whole lot more beyond the text.