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 <[email protected]>

1 files changed, 4 insertions, 0 deletions

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`.