Module history_source 

A document’s history below the toolkit: its steps (undo, redo, restore and checkpoints written into the document itself), the revert they are taken back by, and who wrote them.

The toolkit’s ui::history_source builds the History views on this and keeps its paths; a process without the toolkit reads and moves the same history through the same code.

Modules

authors

Who wrote a change, as data: an automerge actor id decoded to the handle its process chose, the actors one device writes as, and the author a history names, with the colour presence paints them in.

revert

Undoing somebody else’s work: a contiguous run of changes, addressed by what it is rather than by where it sits on a local stack.

steps

Undo, redo, restore and checkpoints written into the document itself, so anyone who can invoke an action can use them: a person, a script, an agent over the action door.

typing

A person typing in one field is one change in History: the keystrokes of a formula, a title or a paragraph, however many words and undo steps they took, are one row until the person stops.

verbs

The resource’s history as actions every app answers, native or tilolang, so the people, scripts and agents working on it can look back, compare and take back through the same door they edit through:

words

How a history verb names steps and people in what it says: a refusal names the step it could not take back and who changed it since.

Constants

DESCRIPTIONS_KEY

Namespaced beside the names of runs, apart from any app’s own schema.

GROUPS_KEY

Namespaced so it cannot collide with an app’s own schema: tilo-doc uses content / comments / props, and the shell’s workspace document uses workspaces / active.

RUNS_KEY

Prefix of the root keys holding this document’s cross-application runs. Namespaced like GROUPS_KEY so it cannot collide with an app’s own schema.

Functions

entry_id_from_hash

The hash is the document’s own content address, so two peers independently building a timeline over the same history agree on the ids — what lets one peer’s [Revert] mean anything to another.

is_description_marker

Whether a change only wrote descriptions.

is_group_marker

True when every patch in patches lands inside the named-range map — used by the producer to keep naming out of the row list. An empty patch set is not a marker: a change that did nothing visible is still a change, and hiding it would be incorrect behaviour.

is_history_metadata

Whether a change only wrote history’s own metadata about other changes: names of runs (GROUPS_KEY), cross-app runs (RUNS_KEY) and descriptions (DESCRIPTIONS_KEY). Such a change is neither a row nor an undo step.

is_run_marker

True when every patch lands inside a run record — the change did nothing but record bookkeeping, already on screen as a band, so a “1 field” row under it would be noise. An empty patch set is not a marker.