The root exec is a click at the keyboard's pane, and goes to its event reader too

A line written to the root's look or exec is a click at the pane with the
keyboard, and in acme every click on a window whose event file is open goes
to its reader; the root's acted at once. It now goes to the reader as the
pane's own does. The docs say what that means for a helper holding event
(its own exec comes back as a record: run it through ctl, or write the
record back), and why an event record counts bytes where acme counts runes:
every offset pardes serves is in bytes, #n and q0/q1 too, so the count
follows them rather than switch alone, and an acme library reads it right
for ASCII text.

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

1 files changed, 9 insertions, 4 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 7361c19e..d0c371c7 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -255,9 +255,11 @@ directory. `body` appends on write and replaces on truncating open. `sel`
 reads the selected text and writing it replaces the selection. `errors`
 appends to the directory's `+Errors` pane. Holding `event` open redirects the
 pane's Look and Exec clicks to that client, and so does a line written to the
-pane's own `look` or `exec`, a click with no place in the text: an `F` record
-at `0 0` carrying the line (the root's `look` and `exec` still act at once);
-writing a record back performs the action. acme takes back only `<origin>
+pane's own `look` or `exec`, or to the root's while that pane has the
+keyboard, a click with no place in the text: an `F` record at `0 0` carrying
+the line. So a client holding `event` that wants a command run gets its own
+exec back as a record: it runs it through `ctl`, or writes the record back.
+Writing a record back performs the action. acme takes back only `<origin>
 <action><q0> <q1>`, the text of that range; pardes takes the record whole as
 it was read too, and for an empty range acts on its text, which is how such
 a line is done. A click in a file's body carries the offsets of the text it
@@ -397,7 +399,10 @@ recorded before anything else.
 Control characters in a record become spaces, so a record is one line.
 (An `event` record is not: acme's `<origin><action><q0> <q1> <flag> <n>
 <text>\n`, whose text may hold newlines; read `n` bytes of it rather than
-up to a newline -- bytes here, where acme counts runes.) An
+up to a newline -- bytes here, where acme counts runes. Every offset and
+count pardes serves is in bytes, `#n` and `q0`/`q1` too; the event count
+follows them rather than switch alone, so an acme library reads pardes
+correctly for ASCII text and not beyond it.) An
 open freezes the ring's text the way `/screen` freezes a frame: reads walk it
 and end. Writing `follow` to that same open makes reads past it wait for the
 next record, one per read; a follower the ring outran reads `lost N` first.