Opening Large Files

Caxton's document model is a memory-mapped piece table with a tiered line index. That is why a 10 GB file opens instantly: nothing is copied, converted, or loaded into RAM up front.

Progressive indexing

When a file opens, the line index builds in the background and the status bar shows its progress. Everything works during the build; the editor renders and edits against whatever has been indexed so far and streams in the rest.

Mid-index on the 10 GB benchmark log. The document is already scrollable and editable; the status bar tracks the background scan.

• 10 GB / 80.6M lines: fully indexed in 19.5 s (measured, M1 Max).
• Memory footprint stays under 200 MB: the file itself is memory-mapped, not resident.

The Large File Controller

Files over a few hundred megabytes get a one-time chooser with the open strategies:

• Whole file (default): the full document, virtualized. This is the right choice almost always.
• Slice: open only a byte range of something truly enormous. The status bar shows the loaded window, and searches/filters label themselves with the slice scope. Filters offer an Entire File toggle that scans beyond the loaded slice.
• Tail: open the last stretch of the file, for the end of a growing log.

Growing logs: watching and follow-tail

Caxton watches open files for external changes. When another process appends to a log, the document absorbs the new lines about once per second. Turn on Follow in the status bar to pin the view to the end of the file as it grows; tail -f, but with search, filters, and full scrollback.

Single-line monsters

A 500 MB minified bundle on one line is a worst case that Caxton treats as a first-class citizen. The renderer draws only the visible segment of the line, so you can jump 267 MB deep into a single line and land instantly, and finding text in it takes under a second.

Encodings

UTF-8 is detected and displayed with the line-ending style in the status bar. Mixed international text (CJK, emoji, combining marks) renders and edits correctly, with caret movement that respects grapheme clusters rather than bytes.

Guessed wrong or working with legacy data? File ▸ Reopen with Encoding reinterprets the file as UTF-8 (with or without BOM), UTF-16 LE/BE, Shift-JIS, EUC-JP, GB18030, Big5, EUC-KR, Windows-1252, or ISO-8859-1.

File pattern rules

Edit ▸ File Pattern Rules… holds an ordered list of glob rules that apply at open: a plain pattern (*.log) matches file names, one with a slash (*/exports/*.csv) matches the whole path. Each rule can set word wrap, tab width, encoding, or syntax and leave the rest inherited; rules read top to bottom and the first match wins for each setting. The encoding rule applies exactly like Reopen with Encoding, just automatically, so the vendor who ships Shift-JIS every Tuesday stops being a ritual.

Comparing files

File ▸ Compare With… diffs the current document against another file: aligned side-by-side differences, at large-file scale (up to 256 MB per side; beyond the edit-distance budget, distant changes collapse into a single "files differ here" block rather than an unbounded search).

Side-by-side comparison: walk the differences with Previous/Next, toggle whitespace sensitivity, and jump straight to any change.