Skip to main content

The Text Editor

Text editing comprises the core of an operating system. Every OS ever provides some way to edit text. Even the terminal or commandline is a text editing experience. We should build the best possible text editing experience into the OS.

Temple OS as inspiration

In Temple OS, the text editor is everything. The commandline is actually a programming experience since commands are compiled as they’re entered. Meanwhile, a special document format (DolDoc) lets users structure text for easy navigation similar to HTML but better because of the way it links to other documents. That’s all part of the same core text editing experience. And that experience distinguishes Temple OS. The text editing experience is all its focus.

Markdown for power

If we use Markdown for structured documents similar to Temple OS’s DolDoc format, we can advance it steps further by allowing code execution via code blocks. Code blocks are executed when documents are opened for viewing. We can use that same concept for any and all text files in the system. All programs are Markdown files, providing simplicity in editing but technical power through executable code blocks.

Indespensable background

If we parse a writer’s text as they’re writing, we can make use of the content. If they happen to be writing a novel, we can create relevant plot or character diagrams in the editor’s background. Similarly, if they’re coding, we can create flowcharts automatically. We can do so elegantly in the background, transparent enough to be out of their way. But we can empower them further by letting them interact with that dynamic background content in ways that can potentially update the original content. If we’re creating character profiles in the background, they can change attributes within the profile and the editor would update the relevant texts. Likewise with coding, if they change the flow of a diagram, we can update the flow of the respective code.

Now make it pretty

The text editing experience should inspire productivity. Many novel writers appreciate a minimalist (or zen) interface when writing. Our OS editor should empower them. It can do more though, and visuals can help.

Consider a theme like this:

Replicating the feel of a chalkboard can yield an inspriring sense of antiquity. It happens to look especially nice with technical computing. Used alongside Hydrogen, the output from inline code block execution meshes perfectly with the blackboard styling.

Subtle animations:

A sci-fi author might especially appreciate a subtly animated, neon cityscape for his composition. And if we’re parsing the author’s text as it’s being written, we can take clues from it and add relevant imagery in the background. Moreover, we can create these themes on-the-fly as the author writes.

Imagine our OS being empowered with a themeable text editing experience like that.


Popular posts from this blog

CSS sans DOM

CSS is amazing, but the HTML DOM isn't. It's just so heavy. Maybe if JSON or some similar format could replace HTML/XML, it could be made lighter? Better, I think, would be to use a human readable format like Eno . It's as terse but much easier to read than JSON.

Compile CSS

CSS is arguably the best means of UI customization. Consider an example of graphic-editing of UI elements: Using CSS, all elements in that project could potentially be done without graphics. Pros practically all designers now know CSS it's vastly capable Cons can't really decouple CSS from HTML whereas HTML is the biggest performance bottleneck (we'll solve this using different means) The Problem Unfortunately, CSS can get incredibly bulky. So what if we could design using CSS in a way that could feasibly be compiled to a local app? In general, everything would be styled using CSS, in the same bulky way it exists in browsers. But when compiled, it's no longer bulky. Benefits we have the full flexibility of CSS for all apps we have the full speed of native apps if needed

Why English

English is not superior to all other languages. It's just pervasive, enough so that many propgramming languages have English constructs built into them. If we're designing a system that uses natural language as a programming language, English is optimal since it's the most familiar.