Split control messages by scope: the root ctl takes the session's builtins and reads the settings, a pane's ctl its own

Every builtin could only be clicked, or written to exec, and the settings
could be read only as the Config window's prose. acme keeps window verbs on
a window's ctl, and webfs and upas/fs keep session settings on a root ctl.
Each builtin now declares its scope (scope = .session; settings are all
session, the rest pane), read by the registry. The root /ctl takes session
builtins and reads every setting in the words a write takes, so its read
written back changes nothing (panel and scene effects now take on/off like
the toggles, to make that true); a pane's ctl takes the pane's builtins
beside get, lock and unlock. Writes are checked whole and refused in Plan
9's ctl words (unknown control message "X", wrong #args ...), which 9ns
now maps to EINVAL (cloud9 re-pinned at a8c7a715). A builtin that would
prompt for its argument fails the write instead, and a refusal is answered
at once, not after the frame.

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

1 files changed, 2 insertions, 2 deletions

diff --git a/src/fs-help.txt b/src/fs-help.txt
index 235ce072..f9e9c6bd 100644
--- a/src/fs-help.txt
+++ b/src/fs-help.txt
@@ -10,6 +10,7 @@ log         recent events, one a line: new/del/rename/save <serial> <name>, and
 screen      rendered screen as JSON, frozen from open to close
 listeners   the session's dial addresses
 focus       the serial of the pane with the keyboard; write a serial to give it the keyboard
+ctl         the settings, one a line as a write takes them; write one, or Newcol, Dump, Kill...
 pane/new    open it to make a pane; the read answers that pane's serial
 pane/<n>/   name body tag ctl addr dot limit data xdata sel dirty mark scroll
             errors event look exec, and pty/ for terminals; rmdir closes it
@@ -26,7 +27,6 @@ Below, $m is the mount point (PARDES_MOUNT in a Tty9p shell; 9ns and 9p work too
   echo 'Msg hello' > $m/exec                   show text in the editor
   echo '#0,#5' > $m/pane/$n/addr; printf NEW >> $m/pane/$n/data  replace bytes 0..5
   cp $m/pane/$n/addr $m/pane/$n/dot; cat $m/pane/$n/sel   select the range, read it
-  cat $m/pane/$n/dirty; echo 0 > $m/pane/$n/dirty         is it modified? say it is not
   exec 3<>$m/log; echo follow >&3; cat <&3     what happened lately, then wait for more
   cat $m/pane/$n/event                         hold it open to own that pane's clicks
   echo exec > $m/pane/$n/pty/ctl               restart a shell; also winsize C R, sig INT
@@ -42,4 +42,4 @@ Pitfalls, one each:
   tag reads path++text; writes append to the text (newlines too); truncating clears it, and dot or addr.
   A terminal's body is a history snapshot frozen per open; pty/data is the live stream.
   A failing command is reported in the editor and in log, not as a write error; a bad line fails the write.
-  pane/<n>/ctl: acme's status line, then current or notcurrent; takes get (reload), lock/unlock on a held fd.
+  pane/<n>/ctl: acme's status line + current; takes get, lock/unlock (on a held fd) and pane builtins (Del).