From d9c6786e19567878e3c89ae212296ce941484096 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Mon, 28 Sep 2026 10:18:59 -0300 Subject: Truncating data or xdata deletes only the addressed range, not the whole body A shell's echo NEW > data opens data with OTRUNC, and truncate() spliced the whole body away before the write replaced the addressed range: a five-byte replacement erased a buffer. data and xdata hold what addr names, so truncating one now deletes that range and nothing else; > on data replaces the range and : > data deletes it, and only truncating body clears the buffer. Co-Authored-By: Claude Opus 5.5 --- docs/fs.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'docs') diff --git a/docs/fs.md b/docs/fs.md index 1b85e4c3..6060949b 100644 --- a/docs/fs.md +++ b/docs/fs.md @@ -235,6 +235,10 @@ address expression (`#0,#5`, `/pattern/`, `2+1`); `addr` selects what `data` and `xdata` read or replace, `dot` is the editor's own selection and moving it scrolls the pane into view, and `limit` bounds a search and reads empty until it is set. Truncating a range file empties it; truncating `limit` lifts it. +Truncating `data` or `xdata` deletes the range `addr` names and nothing +else, so a shell's `echo NEW > data` replaces that range, `: > data` +deletes it, and `>>` inserts at it; only truncating `body` empties the +whole buffer. `addr` belongs to the pane rather than to a client and keeps what was written until someone writes or truncates it, so writing an address and reading it back evaluates it, which is what acme(4) promises of its own `addr`. -- cgit v1.3