A shell's > on addr no longer resets it, so echo /re/ > addr searches on

Truncating addr reset it to #0, so a shell's find-and-replace loop matched the first hit for ever, .+#1 read 1 1 each time, and foo x foo y foo became foobarbarbar... acme resets addr on the first open (xfid.c:105-108), for clients that hold the fid; a shell cannot. Here neither an open nor a truncation resets it: the address written is evaluated from the last one, and 0 or , starts over. Documented as a departure from acme.

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

1 files changed, 6 insertions, 2 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index 6651a9db..756a9785 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -188,8 +188,12 @@ buffer differs from its file, whether a write pushes an undo point, and whether
 a write scrolls. Truncating `tag` clears the part of the tag you may edit.
 
 Address state belongs to the pane, not to a client: it keeps the last range
-written until someone writes or truncates it, so writing an address and reading
-it back evaluates it, and two clients addressing the same pane will interfere.
+written until someone writes another, so writing an address and reading it back
+evaluates it, and two clients addressing the same pane will interfere. Neither
+an open nor a `>` resets it (acme resets it on the first open): each `echo /re/
+> addr` searches on from the last address, so a find-and-replace loop advances.
+Write `0` to start from the top. The search wraps, so stop a find-all loop when
+the address comes back to where it began, or set `limit`.
 `$pane/ctl` reads acme's window status line — serial, tag length, body length,
 a reserved zero, the dirty flag, the width in cells, the font and the tab
 width, then `current` or `notcurrent` — and takes `get` (reload from disk),