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

OpenGL Everything

Recent terminals like Alacritty and Kitty have proved OpenGL is the fastest way to handle text rendering. Xray, the potential next generation of Atom text editor rightly seems to follow suit. Meanwhile, Linux distros like Ubuntu have long been using OpenGL for general rendering to great success as seen with compositors like Compiz.It seems OpenGL might be the best technology for any and all rendering needs. If an OS is built on and uses OpenGL for everything, the consistency could yield great results. Text editing, image manipulation and even office apps would be as fast as possible.

Everything Text

Pixel and vectors, video and text. What if we built one editor that could handle all these cases and more? One editor using one human-readable text format for files. If we use Markdown, we can use code blocks to represent binary data, if needed. Besides being able to store binary data, we could create human-readable data sections using formats like Eno. We could even include executable code.  With the flexibility of Markdown and its respective code blocks, we could store any type of data in a manageable way. So the file format for our all-purpose editor is plain text, Markdown.

We'll build our editor for text processing. But from the start, we must account for all editing needs. We're building a text editor that can do what Photoshop does, and what Premiere does. So first and foremost, everything those editors can do, our editor must be able to do using plain text. From there, we can create intuitive graphic interfaces to facilitate different workflows. Those UIs will basicall…