Text Editor (executable)
Text Editor is a bundled wasm32-wasip1 application. It creates and edits UTF-8 files through the Xila VFS without retaining the whole document in guest memory.
Editing model
The application displays one 4 KiB, UTF-8-safe page at a time. Enter an absolute file path, choose New or Open, then navigate using Previous and Next. Save writes the edited document to the selected path.
Instead of reading the whole file into RAM, the editor works on a temporary on-disk copy and uses fixed-size I/O buffers. A file can be larger than a page without requiring memory proportional to its size.
Storage and failure boundaries
- The parent directory must be writable, with approximately enough free space to hold a second copy of the file.
- Invalid UTF-8 and NUL bytes are rejected; this is a text editor, not a binary editor.
- Saving streams the working copy to the target file.
- A failed save retains the temporary working copy so the user can retry.
- Normal closure cleans up the temporary copy through WASI file unlink support.
The editor is included in the prebuilt guest bundle for new native and browser disk images. Existing persistent disks do not automatically receive new guest binaries.
Working-copy lifecycle and memory costs
The editor separates interface.rs (LVGL guest events) from storage.rs (WorkingCopy). Opening a document creates a unique hidden working file in the same parent directory as the selected source. Files are copied in 4 KiB chunks, validating UTF-8 and rejecting embedded NUL bytes. New documents receive an initially empty working copy.
WorkingCopy::read_page(offset, &mut [u8; 4096]) accepts only UTF-8 boundaries, returns a page length ending on a valid codepoint, and never needs to load the whole document. replace_page edits the on-disk working file while shifting the remaining tail in bounded chunks. The UI retains just the visible text and status, not the complete source file.
Unique temporary file creation tries up to 32 timestamp/sequence candidates. The working copy is removed by its Drop implementation when normal cleanup runs; an abnormal guest termination can leave temporary files behind. The parent directory needs enough free storage for the copy and appropriate create/write permissions.
Save and failure recovery
The UI polls a bounded batch of up to 32 graphics events per turn with a 16 ms sleep. The open/new action and close requests require a second confirmation to discard unsaved edits. Current page changes are committed to the working copy before navigation and save.
WorkingCopy::save_to(target) streams the working data back to the selected path. It does not atomically replace the destination; a failed write can truncate or partially overwrite the original. Keeping the working copy lets the user retry, but it cannot automatically recover a previously overwritten destination after crash/power loss.
The path field has a 240-character UI limit, distinct from the 4096-byte editing page. The default path is /configuration/shared/text_editor/untitled.txt. The working-copy strategy gives roughly constant guest memory use at the cost of extra disk I/O and temporary storage.
Source references
executables/text_editor/src/storage.rs— WorkingCopy, UTF-8 paging, save and Drop.executables/text_editor/src/interface.rs— actions, input length and event loop.executables/text_editor/src/main.rs— installer and guest startup.- VFS subsystem — backing file ownership.