The docs: --detach runs the editor as $!, a line with no newline fails only in the log, data reads to the end

The skill said --detach forks and $! was not the editor's pid; it is, and
/status agrees. A line written with no newline runs at the close, after
the write is answered, so its failure is in the log alone: end lines
with their newline. And `cat data` reads from the address to the end of
the text, as acme's does; xdata is the range.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 7 insertions, 3 deletions

diff --git a/docs/fs.md b/docs/fs.md
index c53f83d6..9b5b9d64 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -502,7 +502,10 @@ whole: a mount cuts a big write at its message size (4 KiB through the
 kernel's, 8 KiB from a client that asks), anywhere, and each piece comes as
 a write of its own, so the open keeps a last line with no newline yet, or
 an Edit block whose text has not ended, until its next write, and runs it
-then; what is left when it closes runs at the close, where an Edit block
+then; what is left when it closes runs at the close -- so a line written
+with no newline (`printf Save > exec`) runs only as the file closes, after
+the write has been answered, and its failure is in the log alone: end each
+line with its newline to have the write itself fail -- where an Edit block
 whose `{` or `a`/`c`/`i` text never ended fails and changes nothing
 (``unmatched `{'``, or `a, c or i text not ended by a . line`, logged as an
 `err`): sam takes the end of input for a `.`, but a block that reaches Edit
@@ -606,8 +609,9 @@ The three range files `addr`, `dot` and `limit` each read the pair of offsets
 they also accept, so copying one onto another is all that acme's `addr=dot`,
 `dot=addr` and `limit=addr` ever were. A write is either that pair or an
 address expression (`#0,#5`, `/pattern/`, `2+1`, and pardes's own `12:5`,
-below); `addr` selects what `data`
-and `xdata` read or replace, `dot` is the editor's own selection and moving it
+below); `addr` selects where `data` reads from -- to the end of the text,
+as acme's does, so `cat data` reads everything after the address -- and
+the range `xdata` reads, just that; either replaces the range, `dot` is the editor's own selection and moving it
 scrolls the pane into view, and `limit` bounds only the end of a forward
 search, as acme's does, and reads empty until it is set. Truncating `dot` empties it, truncating `limit` lifts it --
 though a write after the truncation that fails puts the old limit back, so