1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
# Divergences
What is not on `main`, and what on `main` is known to be wrong. Written so
that moving a bookmark does not quietly orphan work or hide a failure.
## Two lines, forked at `01104e7c`
`main` is not the only living line, and the other one is not behind it —
they are siblings:
```
◆ rruwvuzm 09-17 editor work: syntax, panes, modal, gui, fs, output
│ ◆ xqxpolmw 2b547e15 main 09-20 "Serve Unix and TCP 9P through cloud9.serve"
├─╯
◆ lsnxpxtq 01104e7c 09-16 "Add macOS backdrop blur and preserve PDF ink opacity"
```
* **`main`** carries the 9P work: the `cloud9.serve` runner, and now the
posted-9P registry (`docs/cloud9.md`).
* **`rruwvuzm`** carries editor work — roughly 1300 lines across
`src/syntax.zig`, `src/panes.zig`, `src/modal.zig`, `src/gui/gui.zig`,
`src/fs.zig`, `src/pardes.zig`, `test/output.zig`, `docs/fs.md`. Reach it
with `jj edit rruwvuzm`.
The fork matters for one concrete reason: **the cloud9 pin lives on `main`
only**. `rruwvuzm` still pins `ae310a20` (2026-09-14), `main` now pins
`9c4d668c`. Rebasing or merging the editor line will want the newer pin, or
`zig build` there fetches a cloud9 that predates `fs.Server`'s current shape.
## Other bookmarks
| bookmark | | |
|---|---|---|
| `reload-perf-wip` | 09-11 | unfinished: Reload presentation transport regression |
| `reload` | 09-10 | reload core code with shell-owned allocators |
| `reload-start` | 09-10 | names the Core/Shell seam, deferred Reload request |
| `ninep` | 08-27 | a 9P design note and a design registry to argue it in |
| `macos-fix` | 07-23 | |
| `full-prototype`, `term`, `tty-colors-mouse`, `vibes-ghostty`, `mouse` | 06-xx | older prototypes, also on the `vps` remote |
None of these are published to the FreeBSD mirror: only `main` is pushed
there, deliberately, because that box serves a public site.
## Known-failing on `main`, not caused by the 9P work
* **`zig build snap` fails `nested-optout`, and the cause is a real bug.**
At the SECOND level of nesting -- a pardes whose shell runs a pardes whose
shell runs a command -- two U+E016 codepoints are prepended to whatever is
typed. U+E016 is 57366, which is vaxis's private-use spelling of **F3**
(`Key.zig`, "kitty encodes these keys directly in the private use area"), so
something in the chain is decoding a capability-query REPLY as a key and
forwarding it to the shell as text. bash then sees
`$'\356\200\226\356\200\226echo'` and answers `command not found`; with a
path it answers `No such file or directory` for a path that exists and runs
perfectly from the same shell a moment later.
Minimal repro, in a snapshot script:
```
dirmk innerdir
file innerdir/deeper.txt deepest-marker\n
start 31 100
wait 8000 $
stable 700 20000
text (cd innerdir && $(readlink /proc/$PPID/exe) --nested)
key enter
wait 20000 cwd/innerdir
stable 700 20000
text E=$(readlink /proc/$PPID/exe); "$E" deeper.txt
key enter
settle 5000
stable 700 10000
snap probe
```
`bash: E=/home/.../pardes: No such file or directory` -- bash did not even
parse the assignment, because the line does not start where it looks like it
starts. `--nested` is exactly the flag meant to opt a child out of this, so
the fix belongs next to the key-forwarding path in `panes.Terminal.forwardKey`
and whatever answers terminal capability queries on a nested stdin.
* **pardes does not start headless.** `pardes --9p=<name>` with no terminal
exits 1 from the argument-forwarding path; the installed build fails
earlier still, with `error.NoDevice` opening a terminal device. So the
registry posting above is covered by unit tests
(`zig build 9p-io-test`) rather than by running the editor.
## Upstream
`build.zig.zon` pins cloud9 `9c4d668c`. That commit exists because pinning
cloud9 `534c084f` here failed: cloud9's `build.zig` `@import`s each program's
build fragment, and `9harness` was missing from its `.paths`, so the
published package built from a checkout and not from a tarball. The pardes
build was the first consumer to notice.
|
