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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Clicking somewhere and starting editing mode leads to a desync between the click cursor and the edit mode cursor. For the user they should be the same thing
so if you click somewhere if the cursor moves there the edit cursor should also start there. If its not possible for the edit cursor to be there, then the selection
cursor must also reflect that and move to a place that is 'close' following some heuristic.
The gui backends should receive events from the mouse4 and mouse5 buttons, the ones from logitech on the thumb that works as page next and page previous on the browser by default. For pardes they should work like ctrl-o and ctrl-i .
Add treesitter context, like lets say that the view is in the middle of the function and we cant se its start, the treesitter context should show on the topmost
editor line the declaration of the function, it should correctly show the line number and the code highlited, but it should have some tinting on the bg and maybe a
tiny border on the gui like the tagline has so it looks almost like its the tagline going down a few more rows. It should not just work for functions, but also for struct decls, modules, I'd say any nested declaration that makes sense and you should make sure moving the cursor to there works but it wont move the whole view, but just the cursor and when scrolling up the context declarations will be gradually removed and later you'll find the cursor, it must be seamless. This should be off by default and toggled via a new builtin that will show up on panes where treesitter is active.
The builtins that produce search results like the search and lsp actions and look for files should have some padding between the Location and the result on
the same like so that the Location results are vertically aligned. There should be a new builtin called LocationsConfig that will return the runtime config used
by those, like `LocationsConfig context:5 tscontext:on` it will return the structs fields like this and when running the builtin it will parse input in the same
format using the same comptime info like it used to print the current config, it will only update the keys that were passed. The treesittercontext option
will show the context like the previous paragraph, but since the lines shown are a subset of the file, the context should be shown in order on the output window (and the location for it should be optional configured by the locationsconfig too). There should also be a context options thats not related to treesitter, to show some lines above and below the match, like grep does.
doing ctrl-o and ctrl-i moves the selection, it should not affect the selection, this is a bug.
on tty mode the mouse selection works but the pardes selection on that pane should follow it, the idea here is that we're trying to make it easier to move text
between tty panes without changing the pardes semantics or adding anything extra, just neat tricks like this. Still, you might need to come up with something
to decrease the number of movements/interactions needed to do simple things like copy and pasting text from a terminal to another.
The 9p protocol needs to be simplified and made plan9 idiomatic. Stop leaning on ctl verbs: a name should be the operation. The filesystem should carry more
in stat metadata (real sizes, mtimes, qid versions so a client can poll for change cheaply) and use the real 9P operations for what is currently a ctl verb or a
magic read. cloud9's engine already exposes fs.Features{create, remove, wstat} and the editor backend simply never declared them, so /new creating a pane on
*read* becomes a Tcreate in /pane, del becomes Tremove, cleartag becomes a truncating write to tag, and clean/dirty, scroll/noscroll, mark/nomark and
addr=dot/dot=addr/limit=addr become their own files. What is left of ctl should be only the verbs with no file analog.
shift-esc stopped leaving raw tty mode on the sdl backend. Commit a624a56 moved raw tty keys to an early-return branch that only knew ctrl-B and bare Esc, so
shift-esc was forwarded to the child instead. It is the unconditional way out of tty mode and should stay that way.
On tty mode scrolling should work and not always move the focus down to follow a new line. The terminal only moves down to follow new output when the last line
is already at the bottom, like most terminals and editors. Typing and entering raw mode snap back to live output, so nobody types blind.
The different kinds of layout pardes can initialize (tty mode, file mode, the classic three-shell boot, and the others that already exist) should be an explicit
enum rather than a chain of ifs over tty_only/shells/file/missing. That part of the code needs to be more explicit. The bare tty startup should always start with
an empty text pane at the bottom, not focused.
Nested pardes detection stopped working. Spawning a subprocess should export an env variable holding the pardes pid, so a child can see it and call a Look on the
parent through the 9p mount instead of starting a second session; whether 9p is mounted is another env variable the child can check.
Builtins should call Msg with the builtin name when they are called, minus a few exceptions like Msg itself. This is gated on a verbose config that is on by
default and can be turned off.
The sr.ht upstream has a macos update pushed to it. Pull it, merge it into the tip here as its own change, then look at what the macos backend gained and port
those features to the sdl backend wherever it makes sense.
Config options should print symmetrically with the way they are set: instead of showing transparency with a colon and a percent sign it should read like
`Etcetera 70`, exactly what you would type to set it, and the same for every other setting. LocationsConfig should only open an output window with the current
config when it is called with no arguments.
Closing the last pane in a column should not delete the column: it should leave a new empty pane there instead. A column closes only when it is closed explicitly,
so if there is no builtin for that, add a Delcol that sits on the column tagline by default. And in every tagline the builtin that kills or closes the thing should
come last, which does not look like the case for panes right now.
Pasting regressed on the terminal: inside agent sessions text is being pasted as an image and simply does not work. Reproduce it first, then fix it.
The 9p skill documentation should teach interacting with a running pardes through the /mnt/9p mount with ordinary file tools — cat, echo, ls — as the normal
ad-hoc path, and fall back to the python client only when nothing is mounted.
Dead sessions are never removed from the posted-9P registry, which is a bug. A session that aborts or is killed leaves both its socket in $XDG_RUNTIME_DIR and its
symlink under the registry directory, so /mnt/9p/pardes lists entries that give Input/output error on access. postToRegistry only ever replaces its own name's
entry; nothing sweeps the rest. Posting should sweep the service directory and unlink every entry whose target refuses a connection, and the dangling socket with
it. cloud9 already classifies a refused connect as stale (post.zig Probe), and 9p_io.zig already has `alive`, which treats uncertainty as live -- that is the right
bias, so only a definite refusal reaps.
After all of the above, do an optimization pass on startup time for the gui and tty platforms: measure first, then optimize. build.zig already has a `perf` step
(gesture latency and bounded terminal stress, with --json and a --base baseline to compare against), so a startup measurement belongs there rather than in a new
harness, and the baseline files are how a regression gets caught later.
9p create semantics: doing an action on read is not how plan9 frames it. The canonical pattern is the clone file -- /net/tcp/clone -- where *opening* allocates the
object and reading the fid only tells you which one you got; acme's new/ctl is the same shape, and pardes's old /new already keyed its side effect on open. The
Tcreate that replaced it has a real wart: a pane is named by a server-assigned serial, so the create ignores the client's name and `mkdir /pane/foo` leaves you
/pane/12. Replace it with /pane/clone (open allocates, read answers the serial) and keep Tremove, which is unambiguously right.
TODO, deferred: ligatures on the sdl backend. macOS got them with the first-class-host commit because CoreText shapes for free; sdl rasterises one glyph per
codepoint through FreeType (src/gui/font.c calls FT_Get_Char_Index then FT_Load_Glyph) and FreeType does no shaping, so this means adding HarfBuzz. It is not the
whole renderer, but it is most of the text path: the glyph atlas is keyed by codepoint (GlyphKey{codepoint, role, decoration}) and a ligature has no codepoint, so
the cache rekeys to glyph indices; a shaping stage has to run over runs of same-styled text within a row; and the per-cell instance emit has to place one glyph
across several columns and remember which columns a ligature consumed (macOS does this with ligatureShaped/ligatureCovered). The GPU batching, atlas upload and
scene shaders are untouched. Not worth it until something else wants a shaper.
Not a bug: taglines sit one pixel bottom-heavy when cell_h - tagline_h is odd, because taglineBandOffset splits the spare with a truncating /2. Confirmed
acceptable; leave it.
Startup, measured before optimizing (zig build perf -- --startup, plus timings of the installed binaries):
core Pardes.init + first frame 0.22 ms (tty) .. 0.30 ms (classic) -- negligible
dynamic linker ~25 us, 346 relocations, 4 libs -- negligible
page faults for `pardes --version` 435 -- the 812 MB binary is never paged in, size is a red herring
pardes --version 22 ms real, 21 ms USER, 1 ms sys
pardes-gui --version 107 ms real, 23 ms user -- ~84 ms blocked, not CPU
/bin/true control 1 ms real, 0 user -- the harness costs nothing
Cause found, by profiling rather than guessing (perf record on `pardes --version`):
start.main -> mem.Allocator.alloc
-> heap.debug_allocator.DebugAllocator(.{ .stack_trace_frames = 6, ... }).alloc
-> collectStackTrace -> debug.captureCurrentStackTrace
-> SelfInfo.Elf.unwindFrame -> loadUnwindSections -> Dwarf.Unwind.prepare
-> mem.sortUnstable (22% of all samples sit in mem.swap under the pdq sort)
Zig's own start.main allocates through the Debug-mode DebugAllocator, which captures a 6-frame trace on every allocation,
and the first capture has to parse AND SORT the DWARF unwind tables of an 800 MB binary. That is the whole 18 ms. It is
not lockStderr (added to a hello-world: free), not static initializers (the binary has no .init_array), not the dynamic
loader (25 us), and not paging (435 page faults). std/start.zig:694 hardcodes `DebugAllocator(.{})`, so there is no knob.
Controls: a bare std.process.Init hello-world is 3 ms; the ReleaseFast pardes-perf binary (81 MB, links libc, so
use_debug_allocator is false) starts in 4 ms; /bin/true is 1 ms. The gui binary's one-off 107 ms first run was cold page
cache, not blocking -- warm it is 25 ms, the same as the tty one.
Recommendation: do NOT chase this. 22 ms warm is imperceptible for an editor, the only lever is the build mode, and
switching the default from Debug to ReleaseSafe would multiply an already ~10 minute build to save 18 ms of startup --
a bad trade when the build is the actual bottleneck in this project. Worth knowing for the day a binary ships to someone
else: ReleaseSafe keeps the safety checks, drops the debug allocator, and is 5x faster to start and 10x smaller.
Refactor Msg, and the other transient text a builtin shows (prompts for input and the like), to use the same line mechanism the treesitter context uses rather
than its own. Keep one piece of state on the pane tracking those lines, so several of them do not overlap, so they cooperate, and so removing one puts the rest
back where they belong. Keep it simple.
Startup, the number that actually matters: time to first paint, measured on the real binaries rather than on --version.
pardes --tty on a pty first byte 20 ms, settled 50 ms (8.3 KB in 12 bursts) -- unchanged with LSP enabled
pardes-gui to window map ~330 ms warm, of which ~95% is CPU and only ~30 ms is waiting
The ~1 s that gets noticed is the gui, and ~330 ms of it is real (the rest is presumably paint and content after the map).
Profiled warm (perf record, killed pre-map), by shared object: pardes-gui 28.5%, libc 20.7%, ld-linux 11.9%, libudev 10.3%,
nvidia glcore+eglcore+glsi+gpucomp ~21%, xkbcommon 2%. Cutting across those, DWARF unwinding is 20.9% of all samples --
the Debug allocator's per-allocation stack capture again, now the single largest identifiable slice, bigger than any one
driver library. An earlier measurement of ~510 ms was my own artifact: the probe redirected HOME, so ~/.cache/nvidia was
cold and the driver recompiled shaders every run.
Tried and reverted: deferring SDL_INIT_GAMEPAD until after the first frame, on the theory that libudev's 10% was device
enumeration for a gamepad most sessions do not have. Measured: window map unchanged (320-366 ms before and after) and
libudev only moved 10.3% -> 9.6%. The udev cost belongs to SDL_INIT_VIDEO enumerating Wayland seats and input, not to the
gamepad subsystem. Two fields and a branch for nothing, so it went back out.
Conclusion for both platforms: nothing in pardes's own logic is slow at startup. The cost is the Debug build's allocator
tracing and the GPU/driver stack coming up, and the only lever on either is the build mode.
The Last builtin should fall back to a heuristic when the jumplist has nothing to offer, so the bare tty layout -- a shell with an unfocused text pane under it --
alternates with Last even though that text pane was never focused and is not on the jumplist.
|
