An address searches back after a minus, and a range ending before its start is refused

-/re/ searched forward, since only ?re? set the direction, where acme's
address() takes the direction a minus set (addr.c). And #100,#50 was taken,
leaving data to act on an empty range at 100; sam refuses it as 'addresses out
of order', which acme leaves out, and so does pardes now. The rest of the
dogfood report on addresses already held and is now tested: an expression is
evaluated from the current address, as acme evaluates it from w->addr
(xfid.c:446), so a search starts where the last address or data write left
it and . is that address. Taking . as the selection instead, as the report
asked, would part from acme, which has dot only in its ctl messages; the docs
say which is which.

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

1 files changed, 5 insertions, 1 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index 6346e7b4..49db81b9 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -148,7 +148,11 @@ is why copying one onto another is all that acme's `addr=dot`, `dot=addr` and
 `/pattern/`, `2+1`), whose regexps are mvzr's searched as sam searches:
 `^`/`$` match at any line's start and end, `.` and `[^...]` never match a
 newline, the leftmost match wins (the first alternative there, not the
-longest), `/re/` wraps unless `limit` is set, and a search that backtracks
+longest). An expression is evaluated from the current address (the last one
+written, or just past the last `data` write): `.` is that address, not the
+selection, `/re/` searches on from its end and wraps unless `limit` is set,
+`?re?` or `-/re/` searches back, `#100,#50` fails `addresses out of order`,
+and a search that backtracks
 past a step budget (about 300 ms) fails with `regular expression search
 took too long`. A failed address says
 why (`no match for regexp`, `address out of range`) and leaves no address: