Crate strop_core

Expand description

strop-core: the buffer. A rope, byte-offset positions, edit ops. No UI, no modes, no grammar — the thing everything else edits.

Modules§

history: Undo history (Helix helix-core/history.rs lineage, ported): revisions form a tree — every committed transaction is a node holding both its undo and redo edit sets; u walks to the parent, Ctrl-r descends to the last-visited child. Editing after an undo forks a new branch; the tree keeps the old one (0001 pillar 4: Neovim users expect branches).
id: Stable identities and typed coordinates (0014 wave 2).
layout: The layout layer (0017): one line’s byte↔display-cell maps and grapheme boundaries. Every visible-line consumer — renderer, cursor placement, selection overlays, diagnostics, mouse hit-testing — reads this instead of deriving positions by char index (the old .chars().enumerate() walk drifted after the first multibyte char).
selection: One selection model for everything (0014 wave 2): normal mode is a collapsed selection, visual mode is a stretched one, multicursor is several. Cursor / anchor / extra-cursors used to be three fields that could disagree; the set owns them with the invariants in one place.

Buffer: A text buffer. Positions are UTF-8 byte offsets, everywhere (0001 §5.1).
InputEdit: One edit in tree-sitter’s terms (0022 §1): byte range + point positions, computed from the op itself at commit time — no old text needed (the point extents derive from the op’s own content).
Range: A half-open byte range [start, end) plus its vim shape. Fields are ByteOffset — the storage coordinate is typed end to end (0014).

MotionShape: How vim thinks about a range (0014): charwise ops carry the motion’s inclusivity (dfx vs dtx differ by it); linewise is line-shaped. Blockwise lands with visual block — the enum is the extension point.