---
title: Build a text surface
description: Turn editor or chat state into a bounded viewport of reusable glyph files.
---

Notebook and Chat render editable text as Finder icons. FileDOM has no published
editor component: it provides the rendering primitives, and the applications
supply the editor and conversation logic.

## Separate three responsibilities

| Layer | Owns | Does not own |
| --- | --- | --- |
| Text model | Content, edits, selection, undo, persistence or network messages | Finder files |
| Viewport | Wrapping, scrolling, caret position, visible glyph demand | Document history |
| File rendering | Prepared glyph files, pool allocation, placement, parking | Meaning of an edit |

Capture input into the model independently of repaint completion, so a slow
Finder update cannot collapse two keystrokes into the last one. If only one key
is delayed, check for keyboard remappers such as Karabiner as well.

## Pool occurrences, not just characters

A pool needs one file for each occurrence visible at the same time; one prepared
`E` cannot sit in six positions at once. Start with frequency-weighted reserves,
then account for concentrated demand such as repeated letters or pasted text.
Growing a pool can mean baking and warming more files, so some edits will
allocate.

Keep the viewport bounded. A thousand-line note should not need a thousand lines
of Desktop icons. Reserve transcript and composer capacity separately so
incoming chat cannot use up the files needed for local typing.

Pooling is for the glyphs the viewport cycles through. Fixed labels such as
Saved, New note, and help should mount at startup and keep their files, which
is what [`<Text>`](/docs/reference/components/text) does (its tiles are
[`static` sprites](/docs/reference/components/sprite#where-a-sprites-file-comes-from)).
They warm under the park cover once and are only moved after that. Creating or
unhiding them repeatedly brings back Finder's delayed paint. Use the existing
[text components](/docs/reference/components/text) and
[overlays](/docs/reference/components/overlay) where they fit.

## Layout is not icon size

An icon's square bounds and the text's character advance are different values.
Glyph artwork can fill most of the icon while neighbouring icon bounds overlap.
Choose the advance and line height from the artwork, then check the result in
Finder. Overlapping bounds alone are no reason to add padding.

A caret is another prepared shape. Move a thin caret file to the insertion
point, and blink it by parking and revealing it rather than replacing its
artwork. An optional Neovim backend belongs behind the text model, outside the
glyph renderer.

## Define the supported alphabet

Handle unsupported input explicitly. A limited uppercase font and a small emoji
set are reasonable starting points, but the model must not silently drop text
because its artwork is missing. Either reject the input visibly or display a
documented fallback. Text capacity and glyph capacity are separate limits.

## Study the applications

[Notebook](https://github.com/methodacting/finder-mode/tree/main/games/notebook)
ships in Finder Mode. Its source may be ahead of the packaged downloads; check [status](/docs/guides/status) before treating a feature as released.

Continue with [Stage & Sprite](/docs/reference/components/stage), or see how
[People](/docs/finder-mode/people-and-chat) keeps identity and invitations apart from
rendering.