Make a pane by opening /pane/new, and a Plan 9 idiom pass

The Tcreate that replaced acme's /new was a step away from the idiom dressed
up as a step toward it. A pane is named by a server-assigned serial, so the
create ignored the client's name: `mkdir /pane/foo` succeeded and left you
/pane/12. A mkdir that does not make the directory you named is worse than the
read-with-side-effect it replaced, and it broke in the shell workflow that
motivated the change. `create` is out of the declared features, so Tcreate is
EPERM again; Tremove stays, since `rm` to close a pane is unambiguously right.

/pane/new is now opened, not created: the open makes the pane, the read of
that fid answers its serial, two reads agree, and closing it leaves the pane.
That is /net/tcp/clone's mechanism (kernel/network/ip/devip.c, in ipopen),
not acme's, and the difference is deliberate. acme allocates during the walk
and lands inside the new window, so /dev/new/body works in one step, and it
can afford to list `new` because a Plan 9 directory read carries every entry's
stat and nothing walks. A kernel or FUSE mount walks and stats each name a
listing gave it, so allocate-on-walk would make a pane per `ls -l`. Allocating
on open keeps `new` listed -- a stat is not an open -- at the cost of the
one-step new/body. `new` stays unreachable from an editor path, because that
resolution serves Look hover previews.

The idiom pass behind it, read out of the Plan 9 tree at
~/05-genizah/principia-softwarica rather than recalled:

Rerror carries a string, not an errno (man 5 error: `ename[s]`), and acme
names every refusal. The five refusals pardes shares with acme now say what
they mean; the generic sites keep their bare errno rather than invent strings
acme does not have. body and tag declare DMAPPEND, which they had always
behaved as (acme(4): "always appended; the file offset is ignored"), checked
first against Linux's fs/9p, which never maps the bit. excl stays unset
everywhere, because acme sets DMEXCL on nothing. Blocking reads, per-object
addr scope and the readable pane ctl were already right. Real stat sizes and
qid versions stay: acme reports length 0 and version 0 for everything, and
Linux clients need better.

One bug fell out of it. open reset the addr range, so `echo '#0,#5' >addr;
cat addr` answered `0 0` and `cp addr dot` copied zeros. acme(4) makes the
contract explicit -- "a regular expression may be evaluated by writing it to
addr and reading it back" -- and acme gets away with resetting on the 0-to-1
open only because its clients hold the fid across both. A shell cannot: that
is two opens. The register is cleared by truncating it now.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

1 files changed, 7 insertions, 1 deletions

diff --git a/src/ninep/pane.zig b/src/ninep/pane.zig
index 42c0c48e..4b34cf96 100644
--- a/src/ninep/pane.zig
+++ b/src/ninep/pane.zig
@@ -24,6 +24,12 @@ const Node = tree.Node;
 
 /// Filesystem state a pane carries beside its editor state.
 pub const State = struct {
+    /// The range `data` and `xdata` read and write through. acme clears it
+    /// when the first client opens `addr` (editors/acme/xfid.c:105), which
+    /// suits a client that holds the fid open and leaves a shell reading back
+    /// `0 0` from the address it just wrote. Here it is the pane's own
+    /// register, cleared by truncating the file, so that `cp addr dot` and
+    /// `cat addr` answer what was written.
     addr: Range = .{},
     limit: ?Range = null,
     readers: u16 = 0,
@@ -458,7 +464,7 @@ fn writeRange(p: *Pardes, req: Req, id: usize, pane: *Pane, file: PaneFile) Repl
     const pf = &p.fs.panes[id];
     const text = bodyOf(pane);
     clampAddr(pf, text.len);
-    const r = rangeOf(pf, text, req.data) orelse return Reply.fail(req.tag, E.INVAL);
+    const r = rangeOf(pf, text, req.data) orelse return tree.failText(req.tag, E.INVAL, tree.e_bad_addr);
     switch (file) {
         .addr => pf.addr = r,
         .limit => pf.limit = r,