A 300,000-character manuscript does not have to remain one daily editing file. For a large manuscript text editor workflow, chapters can be separated for navigation while one integrated copy is retained for whole-book search or delivery. The decision is about working structure, not an unsupported promise that every Mac will feel fast.
Reaching the end of a 313,595-character specimen
Rune classified the synthetic file as isLargeFile=true at 313,595 characters. A unique END-211 marker placed at the tail produced one search match. This establishes threshold detection and tail retrieval. It does not benchmark scrolling, typing latency, or autosave across hardware.
Product documentation says that above 300,000 characters Rune disables syntax coloring, editing marks, highlights, line numbers, and continuous counting while retaining editing, search, and saving. That is a load-reduction policy, not a universal speed guarantee.
If the tail seems unreachable, verify a unique end marker and saved state before splitting anything. Then make chapter files for daily work and preserve the integrated source as a controlled export copy. Accept the organization when beginning and end checkpoints remain searchable and chapter order can be reconciled with the integrated text.
Establish a measured baseline before reorganizing
The dedicated source contains 313,595 characters. Rune identified it as a large file, UTF-8 with LF, and found the unique tail token exactly once. These measurements describe one persistent specimen; they do not rank Macs, promise a universal opening time, or prove that automatic saving finished. Their value is as a fixed baseline for checking a later migration.
Choose editorial boundaries, not equal byte slices
A chapter should end where the manuscript's meaning permits it to end. Cutting every fixed number of characters can split dialogue, notes, or a scene. Mark chapter headings, appendices, character sheets, and discarded material first. A workspace can hold the resulting files, but it cannot decide which boundary makes narrative or editorial sense.
Give the workspace an order ledger
Prefix chapter files with spaced numbers such as 010_, 020_, and 030_ so a future insertion does not force every name to change. Maintain an index that records the number, title, source range, and migration status. The index, not the incidental Finder sort order, should be able to reconstruct the manuscript sequence.
Move reference material onto its own shelf
Timelines, character notes, and research can live beside the chapters without being concatenated into the reading manuscript. Open only the reference needed for the current chapter. This reduces the scope of each working view and makes searches intentional: manuscript-only for repeated prose, notes-only for research terms. Any changed local links need a separate old-path/new-path check.
Compare a reversible migration
Keep the 313,595-character original read-only while creating chapter copies. Normalize only the declared delimiters, concatenate those copies in ledger order, and compare them with the baseline. Inspect the opening, every cut boundary, and the unique tail token. The measured source produced one tail match, so the migrated sequence should also produce exactly one.
Large manuscript management is accepted when the index reconstructs every chapter, boundary comparisons reveal no lost or duplicated prose, and the sentinel remains reachable. Perceived responsiveness may improve because less material is open at once, but that is not a benchmark result from this run. The crucial gain is a smaller, reversible unit of work with a surviving source for recovery.
Search scope must remain visible after the split. A sentinel in research notes should not be counted as a duplicate manuscript tail, and a chapter-only search should not be mistaken for a workspace-wide result. Record the folder or file set beside every control query. The same discipline applies to repeated character names: counts only become comparable when the searched revision and scope are identical.
Before closing the migration, perform one reconstruction from the ledger rather than assuming numbered filenames are enough. Concatenate the chapter content in ledger order, normalize only the agreed newline convention, and compare it with the read-only baseline. A mismatch near a boundary identifies the owning two chapters. A mismatch far from boundaries suggests an editorial change that was accidentally mixed into the split.
Workspace management also includes a recovery story. Keep the monolith outside the active sequence, retain its digest, and record when it may be archived. If the index or a chapter becomes damaged, regenerate the relevant range from that source. Automatic backup and restart restoration may be valuable product features, but this CLI evidence did not time or validate them, so they should not be used as substitutes for the explicit baseline.
The final decision is deliberately modest: the source is large by the measured flag, its tail is retrievable, and a chapter-and-index design can reduce the active scope while preserving a reconstruction route. Whether the editor feels faster on a particular Mac needs a separate benchmark. Here, success means that organization did not cost the manuscript its order or its last line.
A collaborator should receive the index revision and monolith digest as a pair. Similar chapter titles can otherwise make an old index look current. Before editing, the collaborator checks that every indexed file exists and that the final sentinel appears in the expected chapter. This small admission test catches incomplete synchronization before new prose widens the difference.
If the organization later changes from sixteen chapters to another count, preserve the earlier ledger and create a new mapping. Historical ledgers explain where review comments belonged at that time. They also keep the current workspace from claiming performance improvements that were never measured; each revision records content structure and scope, while benchmarks remain a separate experiment.