Why Taleno has reading, writing, and code modes

Taleno, previously called Lexora, starts with a small observation: working on a document does not always mean typing into it.

You might read a draft to see whether it makes sense, add a paragraph while an idea is fresh, or inspect a list whose Markdown is not behaving as expected. The file has not changed, but the kind of attention it needs has.

Reading: give the text some room

Reading mode is read-only. Its purpose is to let you follow the document without an accidental keystroke turning a review into an edit.

Think of reading a note from beginning to end before sharing it. At that moment, insertion points and formatting controls are not the main event. A mode that does less can support this particular task better.

Writing: keep the draft and its appearance together

Writing mode is the default. Taleno uses Milkdown and ProseMirror for in-place WYSIWYG editing: you work where the formatted text appears, rather than constantly comparing an editing pane with a preview.

That is a choice about attention. While drafting, I want the next sentence to matter more than the mechanics of marking it up. It does not mean that Markdown syntax should become inaccessible.

Code: leave a direct route to the source

Code mode exposes the Markdown source with line synchronization. It is useful when you want to check indentation, understand a link, or make a precise syntax change.

For example, a nested list that renders unexpectedly is easier to reason about when you can inspect its source. This mode is an escape hatch into the document’s structure, not an instruction to write everything as code.

Three modes should not become three documents

In the editor store, display mode is separate from the document state. The document carries its path, content, and dirty state; the display mode is reading, writing, or code. The mode cycle follows reading → writing → code → reading, and the initial mode is writing.

This matters more than the labels. Switching views should not feel like opening another copy and wondering which one will be saved. The product has to earn that sense of continuity through its behavior.

Local files make the choice tangible

Taleno keeps Markdown on disk. Its file-saving design writes a temporary sibling file before replacing the destination, instead of overwriting the document directly. That also requires write permission on the containing directory — a real constraint worth accounting for in the interface.

There is another implementation trade-off: editing uses Milkdown’s Markdown pipeline, while rendering and export use Rust’s pulldown-cmark. Their edge cases need checking. Three views are not automatically consistent just because all of them speak Markdown.

The question I want to keep testing

After changing modes, can you return to the thought you were having?

That is the standard I want Taleno to work toward: different ways of attending to the same document, without making the switch itself a task.

Read the Taleno product story, or explore the editor state and design decisions. Technical details checked on September 6, 2026.