A limit write that fails keeps the limit it had

A shell's > truncates limit, which lifted it, before the write; a write
that then failed left no limit at all. The truncation now keeps the old
limit until that open's write, and a failed write puts it back; a bare
truncation still lifts it once its open is released.

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

1 files changed, 4 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index e656b66a..c9d5356d 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -470,8 +470,10 @@ 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
 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, and
-truncating `addr` leaves it as it is (below).
+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
+`echo /bad/ > limit` changes nothing -- and truncating `addr` leaves it as
+it is (below).
 
 A rename everywhere, or any other sam edit, is one write to the pane's
 `ctl`: `Edit ,x/foo/c/bar/` runs acme's Edit (docs/tags.md) on the body as