| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for each cell
renderFrame skips the grid cells a body or tag layer paints itself, and it
asked which those are cell by cell: for every cell, twice a frame (counting
instances, then emitting them), bodyLayerAt and tagLayerIn walked all 16 body
layers and all 119 tag layers. In a ReleaseFast profile of a full screen of
src/pardes.zig those walks were about a third of the gui's CPU samples.
coverLayers now fills each live layer's rectangle into a per-cell map once a
frame, and the loops read one byte. The loops only ever asked whether some
layer covers a cell, never which, so overlap order does not enter into it; the
map marks exactly the cells the walks found: a tag layer only its viewport's
first row, and a viewport past the grid only the grid's part of it. The loops
over the layers a panel transition leaves get a second map, built only while
one runs.
A test holds the map to the old walk over a core's layouts (columns, stacked
and collapsed panes, column tags, Tagbottom, message and leader chips) and
3000 random layer sets, some past the grid's edges or at the top of u16.
Hidden captures of 27 layouts (message and prompt chips, a column grip rail,
a PDF, an image, font and tagline changes), with and without leftover edge
pixels, are byte-identical to before.
Over 10 interleaved rounds (160x50 cells), renderFrame's CPU a frame falls
from about 2.0 ms to 0.32-0.37 ms idle, scrolling, typing, under terminal
spew and over a PDF (-82 to -84%, every round), and cell emission from about
1.07 ms to 0.27 ms. The first frame's CPU goes from 6.2 to 4.6 ms.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SDL shell shapes words with HarfBuzz, so a font's `->` and `!=` draw as
ligatures, and there was no way to have the plain glyphs back short of
changing font. `Ligatures` is a toggle, on by default; off, no cell goes to
the shaper and every cell draws its own glyph, exactly as a font without
ligatures does.
It exists only where it means something. A new `ligatures` capability, true
for the gui shell alone, gates it like Font and WindowOpacity are gated: it is
not a builtin elsewhere, has no leader path, and Config does not list it,
rather than print a row the TTY could never change. macOS draws CoreText
ligatures of its own, but nothing there reads the setting, so it stays off
there. The table check that kept every toggle unconditional now lets the
ligatures toggle, and only it, carry a capability, and requires that it
carry `ligatures`; every other setting's rule is as it was.
The gui keeps the setting beside its text caches, which were resolved under
it: when the core's value changes, the per-codepoint cells (which record
whether a cell is shaped) and the shaped words are dropped, and the frame the
toggle asked for draws every cell again. The atlas keeps its glyphs: plain
ones draw either way, and a ligature's strip is reused when it comes back.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The GUI's ligature tests shape `->` and `==` with Maple Mono NF, the only
ligature font in assets/, but the font was ignored, so a checkout without a
private copy skipped the tests or ran them without their Maple half, and
passed. The font is SIL OFL 1.1, whose licence is already tracked beside it,
so it is committed and the tests now fail when it is missing instead of
quietly passing.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
build too
The tty, gui and detached shells allocate from std.start's gpa, which is a
DebugAllocator in Debug and, because we link libc, libc's malloc otherwise.
The macOS shell hardcoded std.heap.smp_allocator in every mode, so its Debug
build checked nothing it allocated outside memory.zig's subsystems.
Which allocator a release build should use was measured rather than
assumed, in ReleaseFast, with an experimental gui that chose at startup
between glibc's malloc and smp_allocator, with and without memory.zig's
stack-fallback buffers, plus an A/A pair; ten interleaved rounds, compared
round by round. The gui frame-cost harness (idle, scroll and typing in
src/pardes.zig, terminal spew, wheel-scrolling docs/design.pdf, first paint)
saw every candidate within the A/A pair's noise. Twelve rounds of the
allocation-heavy paths themselves, highlighting all of src/pardes.zig (305k
tree-sitter allocations) and pardes-pdf-bench's MuPDF renders, split them:
smp_allocator was 2 to 6% slower on MuPDF's page-sized rasters (slower in 9
to 11 of 12 rounds), no better on tree-sitter, and the stack-fallback buffers
changed nothing either way. So glibc's malloc it is, with the buffers kept.
macos.zig now takes a DebugAllocator in Debug, deinitialized in
pardes_deinit with leaks logged the way std.start treats the others', and
libc's malloc otherwise. main.zig says why init.gpa is kept.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a Debug build memory.zig put each subsystem allocator (core, frame, lsp,
tree-sitter, image, PDF) under a DebugAllocator of its own, which is what
reports that subsystem's leaks and makes memory.deinit panic on one. Beneath
it, past the fixed buffer, was the allocator the shell passed in: init.gpa,
which std.process.Init already makes a DebugAllocator in Debug. Every block
that spilled out of a fixed buffer was tracked, checked and given stack
traces twice, and in a test both layers sat on std.testing.allocator.
A Debug build now puts the page allocator beneath the subsystem
DebugAllocators, so each allocation passes through exactly one. The shells'
own gpa is still std.process.Init's DebugAllocator for everything else, and
a release build is unchanged: the subsystems sit on the gpa, no
DebugAllocator anywhere.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the way out
SDL allocated with libc malloc. runNative now installs the shared C heap over
the gui's gpa with SDL_SetMemoryFunctions before SDL's first call: SDL frees
with whichever functions are current, so none of its memory may predate
them. SDL allocates from its own threads too, and the gpa is thread-safe in
every build (a DebugAllocator in Debug, libc's malloc in release).
That put SDL in a Debug build's leak report, and the report filled up: 1769
blocks at exit, because runNative never released its GPU objects, its window
or SDL itself. The process was about to exit, but a report that long hides
any leak that matters. runNative now releases every pipeline, texture,
sampler and buffer the Gui holds, closes the gamepad, destroys the GPU device
and the window, and calls SDL_Quit, all through defers. Eight 32-byte blocks
are left, and they are SDL's: 3.4.4's VULKAN_INTERNAL_DestroyCommandPool
never frees two arrays per command buffer (buffersUsedInPendingTransfers and
texturesUsedInPendingTransfers), which SDL's main branch now frees. They go
away with the next SDL; a comment at the SDL_Quit says so.
The frame-cost harness and a software-present run (PARDES_SOFT_PRESENT) both
run and exit cleanly in Debug.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime
syntax.zig points the tree-sitter runtime at a Zig allocator, but the
grammars' external scanners did not follow it. A grammar's
tree_sitter/alloc.h maps ts_malloc to the runtime's current allocator only
when TREE_SITTER_REUSE_ALLOCATOR is defined, and plain malloc otherwise, so
every scanner's state and its arrays came from libc. Five scanners (bash,
markdown, markdown_inline, python, typst) also call malloc, calloc, realloc
and free by name.
build.zig now compiles every grammar with TREE_SITTER_REUSE_ALLOCATOR and
forces in src/tree_sitter_heap.h, which includes stdlib.h and then defines
the four names as calls through ts_current_malloc and friends. A header
forced in from the build rather than a patch to the grammars keeps zig-pkg
pristine. No grammar archive refers to libc's allocator any more; only the
runtime does, for its defaults. A scanner frees only what it allocated
itself, and the syntax tests that create and destroy a parser for every
grammar under a leak-checking allocator pass.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MuPDF compiled its bundled zlib 1.3.1 (ZLIB_SRC) into libmupdf.a, and the
freetype package links the zlib package, 1.3.2, for its gzip module: 68
symbols defined twice, with the linker keeping one of each. MuPDF now links
that same zlib artifact and stops compiling its own. build.zig asks
FreeType's build for zlib with the options FreeType asks with, which the
build's dependency cache answers with the very artifact FreeType links, so
the tty and the gui each carry exactly one zlib.
MuPDF hands zlib its own allocation functions on every stream, so nothing
about where the memory comes from changes. Every page of the three PDFs in
docs/ still renders bit for bit as before, at 144 and at 300 dpi.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MuPDF compiled its own FreeType 2.13.3 (FREETYPE_SRC, trimmed by
scripts/freetype's slimftmodules.h and slimftoptions.h) into libmupdf.a, and
the gui also links the freetype package, 2.14.3 in its full configuration.
The two define the same 312 symbols, and a linker handed both keeps one of
each: the gui's MuPDF ran the package's FreeType compiled against the slim
headers, while the tty ran the slim one. Now there is one. mupdf.zig takes
the build's freetype artifact, links it (its headers come with it) and no
longer compiles FREETYPE_SRC or puts the slim headers on the include path.
The shared artifact is built at c_optimize, as MuPDF is, so a Debug gui's
glyph atlas now uses a ReleaseFast FreeType too; one artifact cannot be both.
The tty gains the full FreeType's extra modules, which FT_Add_Default_Modules
registers whether or not a PDF needs them. MuPDF asks nothing of FreeType the
full configuration lacks: every page of docs/design.pdf, docs/9p.pdf and
docs/registry.pdf renders bit for bit as before, at 144 and at 300 dpi.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C's malloc, calloc, realloc and free over a Zig allocator were written three
times: syntax.zig's for tree-sitter, pdf.zig's for MuPDF, and gui.zig's for
FreeType and HarfBuzz. They are now one, src/c_heap.zig's Heap. Each hook
names the allocator variable its heap reads; gui.zig exports its heap under
the ui_malloc names font.c and HarfBuzz call. It is a module of its own
because pdf.zig is the MuPDF module, and a file cannot belong to that module
and the core's at once.
A block starts with a 16-byte header holding its size and the allocator that
made it, so it goes back where it came from even after the heap is repointed,
as the fonts' copy did. The fonts' copy carried the 16-byte Allocator itself
in a 32-byte header; here the header holds the allocator's index in a table of
every allocator a heap has used (entries are published once and never change,
and a heap remembers where its current one was last found). The difference is
measurable: with the 32-byte header, pardes-pdf-bench's filtered page render
at 96 dpi took 1.1% longer than before this change, slower in 15 of 16 pinned
rounds in two separate runs, and highlighting all of src/pardes.zig (305k
tree-sitter blocks) up to 0.6% longer, against an A/A pair within 0.7%. With
the 16-byte header both are back within the A/A pair's noise.
Two other things change. For tree-sitter and MuPDF, a block made before the
allocator was repointed now goes back to the one that made it rather than
through the current one. For the fonts, realloc(block, 0) now frees and
returns null, as glibc's does and as the other two copies already did;
neither FreeType nor HarfBuzz asks for it. The heap's test replaces the
tests of the old copies.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first
A message fell in on t*t, an ease-in: it hung near its start for the first
frames and was still moving at its fastest when it hit the row, a sixth of a
row in its last frame. It now decelerates into place with an ease-out cubic,
slide = -(1-t)^3: a quarter of the way in the first frame, and the last
frames only settle it. There is no overshoot. At a row's height and the
dozen frames of the 180 ms fall, a follow-through is a pixel or two, which
reads as a jitter rather than a bounce. MessageFall keeps its 180 ms: the
ease-out puts the chip where it is going within about 100 ms.
The colour leads the motion: alpha = 1 - (1 - min(1, 2t))^2, whole by half
way, so what lands is already legible. The SDL shell used to show the chip
solid while it slid and fade it only on the way out; it now fades it up with
the same alpha, and the rule under a chip carries the chip's fade (a new
TagLayer.fade) instead of standing solid while the chip comes or goes.
The dissolve was an ease-out, (1-t)^2: it lost a tenth of its colour in the
first frame and spent its last frames nearly invisible. An exit eases in
instead, alpha = 1 - t^2 over the same 300 ms: it lets go gently and leaves
faster and faster. t is now counted to the last frame, so that frame shows
it gone rather than it blinking out from 0.3%. 1 - t^3 was the other
candidate; in captures it held the chip nearly untouched for half the
dissolve after the linger had already held it, then dropped a sixth of its
colour a frame, which reads as a pop. It stays in place: the lines stacked
around it do not move, and a drift would read as it leaving its row.
The test pins the shapes: a fast first step into the row, never past it,
solid by half way; a dissolve whose first drop is smaller than its last and
which ends at exactly nothing.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Del takes a side: `Del k` gives the closed pane's rows to the nearest
expanded pane above it, `Del j` to the one below, each falling back to the
other side when it has none. DelAbove and DelBelow are those two lines, with
no path of their own under SPC.
A bare Del started from a key -- SPC d, Enter on the tag word, a row run from
an output buffer -- on a pane with expanded panes both above and below asks
instead of guessing. The question is a prompt like Save's or a search's
(Pane.Prompt.del_side), so it is painted on the pane's notice band by the
same path, and the next key answers it before any mode sees it: k or Up,
j or Down, anything else keeps the pane, as does a click. Only a key press
sets Pardes.can_ask, so a click, a 9P ctl or event write, a startup line, a
restore and a shell exiting all close the pane at once, the rows going
where layout.absorbVWeight has always sent them. A collapsed pane is not
asked about (it has only a tag row to give), and collapsed neighbours are
passed over (layout.expandedNeighbor, which Collapse now uses too).
removePane and absorbVWeight take the recipient; every other caller passes
null. Three scripts that closed a middle pane with SPC d answer k, which
is where the rows went before, and their goldens are unchanged. delask.snap
covers the question, Esc, j, a clicked DelBelow and a clicked Del.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A notice chip -- Msg output, an older message, the leader chord, a prompt --
is a piece of tagline hung over the body's top rows, but in the SDL shell it
ended in a bare edge while the tagline above it ends in a rule. It now has
the tagline's rule along its bottom: the chrome border colour, one pixel,
running on to the window edge when the chip does. A chip still falling into
place brings its rule with it, cut at its row's top like the chip.
The macOS shell already rules every non-workspace tag layer, notices
included; a terminal draws no rule under its tagline, so its chips get none
either.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A builtin that asks for input (Save's path, a search, a pipe) shows its
prompt as a notice chip, like Msg output and the leader chord. Messages and
the chord went through a tag layer, which is what gives a chip the tagline's
height, pitch and band offset; the prompt alone stayed on the grid so its
caret could sit on a cell. A pixel shell therefore drew its tagline glyphs
one to a BODY cell, spaced out like a banner, while the chips around it were
set tight.
The prompt is now a band like the others and carries its caret on the layer,
at the same place in the text the grid pass puts it. The grid still paints
it, for terminal clients. What a band says comes from one place,
noticeText, which the grid pass and the layer pass both read, and what a
prompt says from one place, Pane.promptText, which collectNotices, the
painters and submitSearch share.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shows it
The column grip worked in the GUI but showed nothing anyone could see.
Driving the real SDL window with pixel mouse events, press, drag and
release all reach the core and reorder or resize the column; the feedback
is what failed. The grip kept its muted color while held, and a reorder's
insertion rail was drawn in the gutter cell at the destination edge. The
GUI paints that cell as the column's scroll rail, and at the window's left
edge, the common case of moving the right column first, the dashes were
lost in it. From the leftmost column, a drag short of a neighbour's middle
shows no rail, rightly, since nothing would move, but nothing said the
grip was even held.
A held grip now lights in column_box, the accent its muted color is mixed
from, and the rail takes that color. The rail runs in the seam cell left of
where the column's rule will land, where a border drag's rail runs, for a
reorder and a left-edge move alike; at the window's left edge, which has no
seam, it runs just past the scroll rail, leaving column 0's grip and pane
boxes whole. A carried column's pointer aims at a place, not a word, so the
column tags no longer light the word under it, and a release snaps the
layout as a border drag's does rather than animating it. The preview and the release both
ask layout.columnDrop where the column goes, so the rail stands where the
release puts the edge, and the drag no longer carries its unused column
index.
The GUI test feed takes ESC]777;mouse;<down|up|motion>;<button>;<x>;<y> in
window pixels and dispatches it as an SDL event. test/column_grip.py uses
it to drive the grip through the same pixel-to-cell and tag hit path as a
hand on the mouse, and checks the grip, the rail and the result against
GPU captures and the 9P grid.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeType and HarfBuzz allocated with libc malloc, out of sight of the Zig
allocator the rest of the gui uses, so its Debug leak report and a test's
std.testing.allocator never saw them. Now every allocation the font code
makes goes through ui_malloc, ui_calloc, ui_realloc and ui_free, exported
from gui.zig over `font_allocator`:
- HarfBuzz is compiled with hb_malloc_impl and friends pointing at them.
- Each UIFont gives its FreeType library its own memory manager
(FT_New_Library with an FT_MemoryRec_ over the same functions, then
FT_Add_Default_Modules and FT_Set_Default_Properties: exactly what
FT_Init_FreeType does over its malloc manager), torn down with
FT_Done_Library.
- The shim's own UIFont and scratch arrays use them too.
C's free and realloc pass no size, so a block starts with a 32-byte header
(the caller's pointer stays 16-byte, max_align_t, aligned) holding its size
and the allocator that made it, so a block goes back where it came from
even after font_allocator is repointed. runNative points font_allocator at
the gui's gpa. HarfBuzz makes a few process-wide objects on first use and
never frees them (the default Unicode functions, the locale's language,
hb-ft's font functions); ui_font_prime makes them from the default heap
before that, so a Debug build's leak report stays about fonts. Tests do the
same: the shaping tests, and a new test that creates, rasterizes and shapes
fonts under std.testing.allocator, report any leak. Only the render thread
calls into fonts, and every allocator used is thread-safe.
It costs nothing measurable: against the previous change, 10 interleaved
rounds with an A/A pair show every scenario as fast or faster with Adwaita
Mono and Maple Mono alike, and first paint over 30 launches each matches
main.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
their cells
The SDL shell rasterized every cell by its own codepoint, so a font's `->`,
`!=` or `<=` ligature never appeared. Text is now shaped with HarfBuzz 11.0.0,
built from source like FreeType: a lazy build.zig.zon dependency (the tarball
Ghostty pins) compiled only for the gui shell, its FreeType integration
linked against the freetype package, so the binary carries no system
HarfBuzz or FreeType and a tty build never compiles it.
Shaping turns on only the font's ligature features (liga, calt, clig, rlig,
rclt); composition, local forms and fractions stay off, so a cell draws either
its nominal glyph, as it always did, or part of a ligature. A glyph no lookup
of those features covers cannot change, so its cell is resolved alone, and
that resolution is cached by codepoint: in a font without ligatures (Adwaita
Mono) no cell is ever shaped, and the pipeline draws pixel for pixel as
before.
A cell whose glyph a ligature could replace is shaped with its word: the
cells between spaces that share a decoration and a role. A word ends either
side of the cursor, block or bar, so the cell being edited shows its own
character (Ghostty's rule), and inside f|i, f|l and s|t, whose typographic
ligatures do not belong on a grid (Ghostty again). Colours never end a word:
a ligature spans a syntax colour change or a selection edge. A codepoint the
primary font lacks shapes in the fallback face that has it. Taglines are not
shaped: they are drawn at two pitches, and a strip would not line up in one.
HarfBuzz only chooses glyphs; the grid places them. A substituted glyph whose
ink reaches over neighbouring cells that draw nothing of their own (the
spacer glyphs of Fira Code-style fonts such as Maple Mono, or the cells a
merged ligature cluster swallowed) claims them: it is rasterized once as a
strip that many cells wide, and each cell samples its own slice, so
selection, the cursor and per-cell colours work unchanged. Anything the grid
cannot place (several glyphs in one cell, a positioned mark) keeps its
nominal glyphs.
A frame must not pay for this. A shaped word's atlas slots are cached by its
text (checked against the stored text, not just its hash), so a frame costs
one lookup per word and a compare for the rest of the word being walked.
The atlas is keyed by (face, glyph, role, decoration, lead, span), packed into
64 bits so a lookup hashes one word; ASCII glyph ids are a table, and a
face's HarfBuzz state is made when it is first asked about a glyph. Measured
with the latency trace, whose F line now also carries the submit time (CPU =
submit - present entry), in 10 interleaved rounds against main with an A/A
pair, at 160x50 cells: with Adwaita Mono every scenario (idle, scrolling,
typing, terminal output) is as fast or 1-3% faster, and the first frame and
time to first paint are unchanged. With Maple Mono, ligatures cost the first
frame about 0.8 ms (HarfBuzz setup and shaping the screen) and scrolling new
text about 1-2%.
With it the codepoint raster path is gone: grips look up their glyph and
stay centered, since a grip is not text. ui_font_scale_for_height, an
identity kept as a "size token", is removed (px is the size everywhere),
ui_font_has_glyph becomes ui_font_glyph, and the space slot is simply the
first, cleared cell of the atlas rather than a rasterized space. CellStyle.ul
gets an explicit u3 tag so a decoration fits in the packed keys.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stb_truetype sources
Bold in the SDL shell was a smear of the finished glyph: every pixel took
the larger of itself and three quarters of its left neighbour. That added a
grey fringe on the right of each stem instead of a thicker stem, so bold read
as blurred regular text, and at large sizes it barely read as bold at all.
The rasterizer now does what Ghostty's FreeType face does: it loads the
hinted glyph, thickens the outline with FT_Outline_Embolden, and renders
that. The stems widen as one shape with hinted edges, and the advance is
untouched, so the cell grid, caret and selection do not move. The strength
is Ghostty's heuristic, 1/32 of the line height rounded up (one pixel at a
32 px line). A bitmap strike has no outline; it is widened by one whole
pixel with FT_Bitmap_Embolden, the classic overstrike. Underline and
strikethrough are still drawn into the cached cell mask (decorateLine).
vendor/stb (stb_truetype.h and its implementation unit) was left over from
the rasterizer FreeType replaced; nothing built or referenced it.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resize columns from their grip
Every tag band (workspace, column, pane) is centred in its row, so text sits
at one baseline offset. Anchors are inset from the column rule by that same
margin, so they are square and the band frames them on the left, top and bottom;
the pane mark moves to stay centred. When the window is not a whole number of
cells, the bands, rules, spines and scroll thumbs at the right and bottom edges
run on through the leftover pixels.
A column grip dropped short of another column's place now moves the column's
left edge, with a dashed rail preview, sharing setColumnPairWidth with the
border drag. A release still on the grip changes nothing, and a pair too
narrow for two MINW columns is left alone.
PARDES_TEST_PAD adds leftover pixels to a test-mode window and capture.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
messages
PDF highlights (hover preview, search, selection) are baked into page rasters,
and any change re-rendered the whole page with MuPDF; the TTY then re-sent it
as base64 (4.7 MB a page), the GUI as a new texture. Worse, a pointer motion
over a PDF invalidated the page even when no preview was shown, so every
motion paid that. Now:
- A raster whose baked highlight set equals the wanted one is left alone.
- A highlighted page keeps its clean rows (before highlights and tint); a
change repaints only the rows of quads that differ, running MuPDF's
highlight pass (pardes_pdf_paint_highlights) over those clean rows and
tinting them: the operations a full render performs, so the pixels are
identical. MuPDF band renders are NOT bit-identical to a whole page (edge
rows, resampled images), so they are never used to patch; the comment
claiming otherwise is corrected.
- ImagePlace.patch hands shells the changed rows; the GUI uploads just those
rows into the texture it holds.
- The TTY probes kitty shared memory (t=s) with an id vaxis never reaches and
sends rasters as a /dev/shm name when the terminal reads it; direct base64
otherwise (ssh).
- Shells that take row patches (GUI, TTY with shm) repaint a selection while
it is dragged instead of only on release.
Latency elsewhere:
- TTY: an animating frame no longer sleeps 16 ms blind; a tick thread posts
into the input queue, so input inside the frame is handled at once.
- TTY and GUI: queued pointer motions coalesce to the last.
- GUI: a skipped swapchain image re-arms the frame (3 retries); animations
still tick while nothing presents.
- Editing: the line index is carried across an edit instead of rebuilt from
a scan of the whole file per keystroke.
Messages fall into their row (ease-in; the GUI slides the band out from under
the tagline, a terminal fades it), stay until the next input as before, linger
MessageLinger ms (default 800), and dissolve (ease-out). MessageAnimation
toggles it; both are settings, in Config and startup files. The snapshot
harness pins the old behaviour. The detached server now ticks animations.
A restored terminal comes back live: the old screen and scrollback (dumped
as clean VT by ghostty's formatter, replayed at the new size; older dumps
fall back to their rendered text), a dim
"restored history" marker, then a new shell in the directory it was in.
Right-click on a line number in a file pane looks at that line (a sticky
context header's number included).
Measured with an external pty driver (TTY), an in-process fence trace
(GUI, PARDES_TEST_LATENCY), and test/pdf_pointer_bench.zig (pixel identity
against the baseline and a whole-page oracle); balanced A/A/B rounds, paired
per-round statistics.
Messages stack: each event gets its own row and its own fall, linger and
dissolve; a line keeps its row until it leaves and a new one fills the first
free row. Announcements and statuses are replaced in place, not stacked.
MessageFall, MessageDissolve and DumpDir are settings Config reports.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The editor's loop was the only thing that could answer a 9P request, which
made the editor's own syscalls through a mount of its own tree -- a Look at
/mnt/9p/pardes/<me>/anything under a `9ns --mntgen` view, a Save into it --
requests only the blocked loop could serve. The name-based refusal that
followed (ownMountSuffix) and the in-process routing of a mount of oneself
(Client.sameSession) were patches over that, and both are gone, with the
mailbox that shipped every request to the editor's thread.
One rule replaces them, `pardes.turn`: the core is single-threaded, the
editor's thread has the turn by default and gives it up in two kinds of gap
-- while it waits for input and while a step of it is out in a host syscall
-- and a cloud9 connection task takes it in those gaps to answer. `out`
counts the steps that are out, from any thread: while one is, the core reads
consistently but that step still holds pointers into it, so a request that
would change a pane (a write, a truncation, an rmdir) is parked in the
engine and retried when the turn is next given up with nothing out, and the
editor's own wake waits for the count to reach zero. It is never a write of
its own that a step waits on out there -- writes come from a shell
performing a save between steps -- so a parked request is never the
syscall's own, and making a pane or rendering a screen need not park:
every yield sits before its step's mutation, so the layout and the surface
are whole under it. A changing request that queued effects is answered
once the editor has performed them (`echo Save > exec` returns with the
file written, as acme's `put` does), and it settles the way a step does,
because without that a /log reader waited for the user's next keystroke.
Every host syscall on a user path has to give the turn up, not fs.zig's
alone: the first end-to-end run hung in `inotify_add_watch` performing the
new pane's watch effect. PDFs and images are read whole at open, so no
draw goes out into the host. The core's allocator takes its fixed buffer
through the lock-free interface, since a connection task allocates while
the editor's thread is out in a syscall that allocates too. A Restore puts
the replacement in first and releases every task waiting on the old core.
cloud9 (pinned at eb1a104) parks an open, a truncating wstat, a clunk and a
remove on `again`, not only reads and writes, and answers a parked job
whose fid was clunked without asking the backend.
Verified: test/selfmount.py runs the editor under `9ns --mntgen` and
Looks at, reads and Saves its own tree through the mount; a unit test pins
that a change parks while the editor is out mid-step and lands when it
rests, while a read is answered in the window. 9P over the Unix socket
against a tty session, same machine, Debug builds: a read of /index 278us
-> 61us, a truncating body write 1184us -> 609us, exec Save 718us -> 583us;
the gesture benchmark is unchanged (geometric mean 0.997 over 53 cells).
Also from the reviews: a notice chip over an image or PDF pane was painted
out by the picture drawn after the cells, so pictures give up the rows; in
the GUI a tree-sitter context band painted over the chip, so body layers
are emitted first; a message is one row of printable text, its 256-byte
cut never leaves half a glyph, and one wider than its pane keeps its tail
(the file name, the reason) rather than its head.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A notice is an overlay now, which is the one place it is NOT like the
tree-sitter context: it takes no row from the body and moves no text. Each one
is a chip as wide as its own message plus a blank cell either side, anchored
to the pane right edge on the body top rows. The rest of each of those rows is
ordinary body text that still reads and still answers a click -- Notices.left
records where each chip starts, and the hit test refuses only the cells it
covers rather than the whole row.
The width is counted in GRID columns rather than scaled into the tagline face
the chip is drawn in, because the canonical grid is what a terminal client
draws and a chip narrower than its own text there would clip it; the narrower
tagline face simply leaves a little more room inside the chip. The tag layer
takes the geometry the grid pass already chose, so the two cannot disagree and
the GUI skipping the cells a tag layer covers leaves no stub behind.
Pane.body_offset is gone with the reservation it existed for, and bodyTop
takes only a rect. The body layer keeps every row it had, the scrollbar runs
the full body again, and the GUI smooth-scroll extents go back to the pane.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A message, a leader chord and a prompt used to share one row of body text at
the bottom of a pane, wearing the tagline font and nothing else about a
tagline. Now each one is a TagLayer of its own, emitted through the same
renderHeaderLayer the pane and column tags go through, so it gets the tagline
height, the small-font metrics, the band offset and the border for free --
none of which a body-grid row can have by changing its font role. The text is
right aligned. The prompt stays on the canonical grid because it owns a
cursor, and a cursor has to sit on a real cell.
The body starts BELOW the bands rather than under them, the way tree-sitter
context rows already worked. Pane.body_offset is how many rows they took and
Pardes.bodyTop(pane, rect) is the one place that answers "where does the body
begin" -- replacing fifteen copies of `if (tag_bottom) r.y else r.y + BOX_H`
spread across the paint, hit-test, scroll, PDF and image paths, which is what
let the bands and the text under them come adrift. Every notice is painted on
the grid as well, because the grid is what a terminal client draws and a band
it cannot see is a message it never gets; the GUI skips grid cells a tag layer
covers, so nothing is drawn twice.
Three bugs the bands exposed, fixed here:
- a prompt band flush with the right edge put its caret one column past the
pane, which the detached wire refuses -- so every frame was dropped for as
long as the prompt was open. The band now reserves that column.
- a click on a band mapped to Sel row 0, which is the TAG row: clicking
chrome expanded a word out of the tagline and ran it as a builtin.
- a watched file reloading under the editor changed the core without going
through update, so needs_frame was never set and the reload was never
drawn. Pardes.invalidate() is the name for that, and the file and theme
reloads call it.
A session can now drive its own 9P namespace instead of being refused one:
ownMountSuffix answers what a path names inside this editors own tree and
resolve, readLimit and write serve it from memory rather than making the
syscall that never returns. The match is anchored to whole components under
the registrys 9p/pardes/<name>, because a bare /pardes/<name> anywhere in a
string would claim ~/src/pardes/<name>/README -- and, before write learned the
same trick, write the trees bytes over the real file. readFileLimit and
writeFile refuse instead, having no core to answer from.
A toggle setting SETS when given `on` or `off` and only flips when it is bare,
so the report LocationsConfig prints can be fed back as configuration and mean
what it says.
Snapshots: 97/98, from 0/98. The goldens were several commits stale and 17
scripts had stopped running; `config <line>` is a new script command that
appends to the per-script startup config, so a script that clicks body
coordinates pins `Verbose off` instead of counting the rows an announcement
moves. nested-optout is left failing on purpose: two levels of nesting prepend
vaxis F3 codepoints to typed lines, which is a real bug and is written down in
docs/divergences.md with a repro.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a path inside this editor's own 9P tree hung the session outright, and
it is easy to do by accident: a file manager whose $EDITOR is pardes, or a Look
at anything under /mnt/9p/pardes/<me>/. The realpath, the stat and the read all
leave through the mount and come back as 9P requests only this editor's loop
can answer, while that loop is blocked making them. The filesystem then stops
answering anybody, which is what made it look frozen rather than slow.
The answer has to come from the NAME, before any syscall, because the syscall
is the thing that never returns: the listener notes the name it is posted under
and `resolveOs` refuses a path containing `/pardes/<that name>/`, with
`readLimit` refusing it too for anything that gets past resolution. Another
session's mount stays perfectly usable, and `/n/self/...` is the way to reach
your own tree -- the editor serves it from memory without leaving the process.
Reproduced before and after: the 9P write that never returned now returns, the
editor stays responsive, and it spends four CPU ticks doing it.
The transient lines also now look like what they were modelled on. They carried
the context band's bookkeeping -- one list, rows reserved the way sticky
headers reserve them -- but still painted as ordinary body text, so a message
read as a stray line at the bottom of the pane rather than as part of its
chrome. They take the tagline font and the tagline's own colours now, verified
on a running editor: the announcement lands with font_role=tagline.
Two tests the features never had: a builtin announcing itself, reaching the
notice list, being overridden by Msg's own text and silenced by Verbose; and
the own-mount guard, including that a session with no listener refuses nothing.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The registry sweep could delete a live socket, anywhere on the filesystem. A
reviewer reproduced it: a socket that is bound but has not reached listen(2)
answers ECONNREFUSED exactly like a dead one -- that window is every server's
startup -- and the sweep then followed the entry's symlink and unlinked
whatever absolute path it named. It now follows a target only into the
directory our own sockets live in and only to a `pardes-9p-*.sock` name, it
re-probes immediately before deleting rather than trusting a probe that is by
then several syscalls old, and a readlink that exactly filled its buffer is
treated as the truncation it is. The test grew a case for an entry whose
target is not ours: the entry goes, the file does not.
Ctrl-V in raw tty mode was a black hole when the yank register was empty --
neither typed nor forwarded -- so vim's visual block, readline's quoted-insert
and every other program's Ctrl-V simply vanished. With nothing to paste the
chord belongs to the program again.
The lone-ESC flush added earlier was dead code. vaxis already returns Escape
for a one-byte 0x1b (`Parser.parseGround` asserts `input.len == 1`), so the
carried byte it waited for can never exist; a reviewer showed a 3 ms gap and a
60 ms gap behaving identically. Removed rather than left to imply a guarantee
it never provided.
A shell whose editor is gone can start one again. Naming a live but
unreachable session made `pardes <file>` exit 1, which let a stale environment
variable lock someone out of their own editor; it falls through to an ordinary
session, as it did before the variable existed.
Also: the macOS ABI check for `pardes_topbar_pane_border_px` had been replaced
by a duplicate of the line above it; `--startup` now fails on a leak the way
every other measurement in that file does, and stops calling its maximum a p95
below twenty samples; the served README and the skill no longer tell you to
write to `data` with `>`, which truncates the whole body before the write
lands; `docs/v9fs.md` described the allocate-on-walk design that was rejected;
and `test/fs.py` keys nesting off `PARDES_PID`, so its forwarding case stops
passing only when the runner happens to be inside a live pardes.
fs-test now reaches its one documented pre-existing failure instead of dying
early. Suite 778/783 with the two known crashes.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A 9P round trip on a local Unix socket cost 9.7 ms against the SDL shell and
0.758 ms against the terminal one. The server was not slow and the wake was
not broken: instrumenting the path showed every request waking the loop early
(wakes=210, woke_early=212, timed_out=38 over 250 ticks) and being answered on
that same pass. The cost was that `pump` answers 9P at one point in a loop
that then renders and presents unconditionally, so a client's next request
landed while the main thread was blocked on the display, and each round trip
therefore cost a whole frame. The frame rate was governing something that has
nothing to do with drawing.
`Pardes.needs_frame` starts true, is set by every event except a tick with
nothing animating and a filesystem request that only reads, and is cleared
once a frame is presented. `pump` returns before render and present when it is
false and nothing is animating. An idle editor answering reads now draws
nothing at all.
9P read_fid, one RPC: gui 9.7 ms -> 0.056 ms (173x)
tty 0.758 ms -> 0.062 ms (12x)
Verified the shells still paint rather than going quiet: the rendered screen
carries the opened file, a write through 9P redraws within the frame, and
`fs-discovery-test` passes over the real wire. Suite unchanged at 778/783 with
the two pre-existing crashes.
Also from the adversarial review of the previous commits:
`pardes --tty FILE` silently discarded the file, and `--tty MISSING` silently
discarded the error pane. main.zig named the boot layout before the positional
was resolved, and naming one short-circuits `Boot.of`. The choice now happens
after the argument is known, and only when there is no file and no missing
word. macos.zig names the same layout, so the app no longer boots a different
one from the terminal and SDL shells.
`pre_close_last_pane_tail` was transcribed from the NEW default rather than the
old one, so the upgrade path it was added for did not exist: a workspace dumped
before the tagline reorder came back with the old default welded on as a custom
tail. It is now the string it claims to be.
A pane two rows tall lost its message and, worse, its prompt and the cursor
with it. The notice cap keeps the LAST notices now, because the prompt is last
and a prompt you cannot see is one you type into blind.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A pane's message, its pending leader chord and a prompt waiting for input all
wanted the same row above the tagline. The prompt won it, the leader drew over
whatever was there on the right, and renderBodyLayer recomputed "is anything
down there" inline to reserve a single row. Three claimants, one row, and two
places deciding.
Pane.Notices is that decision in one place: a short ordered list of the lines
a pane is showing, rebuilt every frame by collectNotices from the state that
owns each one. The body layer reserves exactly notices.len rows, the way it
already reserves rows for sticky context headers, and the paint pass walks the
list and gives each line a row of its own, stacked upward from the tagline.
Nothing stores a second copy of the truth, so a line that goes away is simply
not added next frame and the rest close the gap. One notice lands on exactly
the row the message always had, and the prompt stays nearest the tagline so it
keeps its cursor.
Last also learned what to do when the jumplist is empty. It used to walk the
jumps and, finding nothing, do nothing at all -- which is the ordinary case
for a pane that opened beside this one and was never focused, such as the text
pane the bare tty layout puts under the shell. It now falls back to
neighbourPane: the next pane down the column, wrapping, and any other live
pane failing that. Alternating with the neighbour is what Last is for.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--version measures a process that exits before doing any work. On a pty the
tty shell emits its first byte at 20 ms and settles at 50 ms; the gui takes
~330 ms to map its window, and that is the latency worth noticing.
Of the gui's 330 ms, ~95% is CPU and only ~30 ms is waiting. Profiled warm and
killed before the map: pardes-gui 28.5%, libc 20.7%, ld-linux 11.9%, libudev
10.3%, the nvidia stack ~21%. Cutting across all of those, DWARF unwinding is
20.9% of samples -- the Debug allocator capturing six frames per allocation,
the same cost the previous change found, and now the largest single slice.
Two of my own measurements were wrong and are corrected here. An earlier
~510 ms figure was an artifact: the probe redirected HOME, so the nvidia
shader cache was cold and the driver recompiled every launch. And deferring
SDL_INIT_GAMEPAD past the first frame, on the theory that libudev's 10% was
gamepad enumeration, changed the map time not at all (320-366 ms either way)
and libudev only 10.3% -> 9.6%: that work belongs to SDL_INIT_VIDEO bringing
up Wayland seats. It is reverted rather than kept as an unmeasurable win.
So nothing in the editor's own logic is slow to start. What is left is the
Debug allocator and the GPU stack, and the only lever on either is the build
mode -- which is not worth tripling a ten-minute build for.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A --startup case in the perf harness times Pardes.init and the first frame for
each boot layout, with the same --json and --base shape as the others, so these
are a baseline rather than a one-off reading. The core boots and paints in
0.22 ms (tty) to 0.30 ms (classic): about one percent of what starting the
editor costs, and nothing to win.
The other 99% is one thing, found with perf record rather than guessed at.
Zig's start.main allocates through the Debug-mode DebugAllocator, which
captures a six-frame stack trace per allocation, and the first capture parses
and sorts the DWARF unwind tables of an 800 MB binary -- 22% of all samples sit
in mem.swap under that pdq sort. It is not the dynamic loader (25 us), not
static initializers (the binary has no .init_array), not paging (435 page
faults), and not lockStderr. std/start.zig:694 hardcodes DebugAllocator(.{}),
so there is no knob short of the build mode.
Controls that pin it down: a bare std.process.Init hello-world starts in 3 ms,
the ReleaseFast pardes-perf binary in 4 ms, /bin/true in 1 ms, and a Debug
pardes in 22 ms. The gui binary's 107 ms first run was cold page cache; warm it
matches the tty one.
So the conclusion recorded in features.txt is to leave it alone. Twenty-two
milliseconds is imperceptible for an editor, and the only lever is switching
the default build mode, which would multiply an already ten-minute build to
save eighteen milliseconds of startup.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Pty children are exec'd with their own TERM/COLORTERM/TERM_PROGRAM instead of
inheriting a .app launch's empty environment, and ttyTaken finally answers on
darwin — libproc walks the tty's foreground process group — so Escape reaches
the child and Exec stops believing every pane sits at its prompt. The
occupancy suite runs on both platforms now.
The workspace tag row moves into the native menu bar as a Builtins menu.
-Dworkspace-tag (default off for -Dplatform=macos, on everywhere else) drives
it, and Pardes.topBarHeight replaces the TOPBAR_H constant so the core stops
reserving the row.
The view pins every variable-font axis to the file's own default (Maple Mono
came up Thin otherwise), shapes ligatures, carries per-shape pointer cursors,
and draws the look-hover affordance as refracted glass. Tag rows fill edge to
edge, with the anchor box painted back on top of that fill and its mode glyph
centred on the same square. Theme accents re-saturated across the set.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The 9P tree stops being a command language wearing a filesystem. /new
created a pane as a side effect of a *read*; it is now Tcreate in /pane,
with Tremove to close, which cloud9's engine has always supported and the
editor never declared: tree.zig now says
`features = .{ .create = true, .remove = true }`. Eleven pane ctl verbs
become files that can be read as well as written -- dot, limit, dirty,
mark, scroll, look, exec -- leaving ctl with `get`, the one verb no file
would say better. Root /ctl splits into a read-only /status and the
/look and /exec files whose write IS the click. stat carries real sizes
where it used to answer 0, and qid versions track a pane's revision, so a
client can poll for change without re-reading the body.
Commit a624a56 moved raw-tty keys to an early-return branch that knew only
Ctrl-B and bare Escape, and in the same edit deleted the paste branch below
it. That cost Shift-Escape (the unconditional way out of tty mode) and both
paste chords: Ctrl-V and Ctrl-Shift-V reached the child as keystrokes, so an
agent CLI running in a pane took Ctrl-V for its image-paste binding and
answered "No image found in clipboard". Both are restored, with tests.
Nested detection was not subtly broken but deleted: 60367d8 removed
nested.zig's process-ancestry walk and left "am I inside pardes" derived from
PARDES_FORWARD_LOOK, which read "0" both for --nested and for "the listener
did not come up". PARDES_PID now answers that question on its own, checked
with kill(pid, 0); PARDES_9P and PARDES_PANE answer how to reach it; the flag
is gone. The posted-9P registry also self-heals now -- a session that aborts
cannot unlink its own socket, so posting sweeps entries whose target refuses
a connection, symlinks only and on a definite ECONNREFUSED only.
Elsewhere: tty scrolling is sticky-bottom, following new output only from
the last row, with typing and entering raw mode snapping back to live; the
boot layouts are a Boot enum instead of a chain of ifs, and the bare tty
startup (Boot.tty, which main.zig names) opens an empty text pane under the
shell while tests keep Boot.tty_shell; builtins announce themselves on the
message row under a Verbose setting that is on by default; Config prints
each setting the way you would type it back, so WindowOpacity 70 rather than
"WindowOpacity: 70%"; LocationsConfig opens its window only when called bare;
every tagline puts the word that closes the thing last, and a column now
outlives its panes -- closing the last one leaves an empty pane, and only
Delcol, newly on the column tagline, takes the column away.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pardes spoke 9P and could be mounted, but only by naming its socket:
$XDG_RUNTIME_DIR/pardes-9p-<name>.sock sits one directory above the
registry and nothing could find it. Now a listening editor advertises
itself at $XDG_RUNTIME_DIR/9p/pardes/<name>, a symlink to the socket it
already binds. One directory for the program, one entry per editor —
the layout zmx posts its sessions under — so several editors group
rather than crowd the registry root.
The socket does not move: adopting the registry only advertises. Only
the runtime-directory socket posts, so an instance on the
~/.local/state fallback stays out of the user's registry, the way a
private ZMX_DIR does for zmx. Stopping unposts, and only while the
entry is still ours, so a name another editor has since claimed is
never unlinked. The cloud9 pin moves to 9c4d668c for cloud9.post's
path helpers.
Serving is the whole of it. Consuming the registry is 9ns's job: it
mounts the lot at /mnt/9p and an interactive fish already self-wraps in
one, so a pardes started from a terminal reads /mnt/9p/harness/... with
the same code that reads any other path. Two drafts that taught
`resolve` to dial the registry itself were reverted — one duplicated
9ns for no gain, the other reinterpreted relative dials, which are a
feature. `resolve` is byte-identical to what it was, and no dial that
worked changes meaning.
What pardes still does not do, and why, is in docs/cloud9.md: it binds
its own socket rather than posting through cloud9.post, because post
claims flat names only — legalName rejects '/', and claimName derives
its lock directory by stripping "/9p" — so a name inside a subdirectory
cannot go through it. zmx hand-rolls the same symlink for the same
reason. Unifying them means teaching post a group, which is a change to
adversarially-hardened code rather than a rename.
docs/divergences.md records what this bookmark move leaves beside it:
the editor line rruwvuzm (~1300 lines, forked at 01104e7c, still on the
old cloud9 pin), the other bookmarks, and two failures that are not
this change — fs-test's syntax-highlighting assertion, which fails
identically on a clean main, and pardes not starting headless, which is
why this is covered by 9p-io-test rather than by running the editor.
Tests: 11/11 9p-io-test, including a listener that posts on start and
unposts on stop; 31/31 unit-test.
|
| |
|
|
|
|
|
|
|
|
|
| |
The hand-written poll loop for Unix/TCP listeners is replaced by
cloud9.serve.Runner; requests are queued to the editor thread, which answers
them under the connection lock on each frame and retries parked reads as
before. QUIC keeps the poll path (its adapter is fd based). The detached
server no longer loses a wake that lands between frames. The firmware path
keeps driving the engine with push/step. cloud9 re-pinned.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
src/9p.zig shrinks to an 88-line alias: the engine and the backend contract
(Req, Reply/ReplyWith, Op, Status, Attr, E, error strings) now come from
cloud9.fs. The editor's limits become cloud9.fs.Options values; the ESP32-P4
board backend drops its own copies of the contract types. No behaviour
change; fs-bench still allocates nothing per request. cloud9 re-pinned to
the commit that carries the engine.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The served tree loses the self/ level: /index /ctl /new /log /screen
/listeners /pane/<n>/... /os, with /src only in -Dembed-sources=true builds
(default off, on for esp32p4). ctl speaks the editor's own language with two
lowercase verbs, look TEXT and exec TEXT, plus acme's addr verbs; the new/
factory directory becomes one clone file; cons is gone (exec Msg); name and
sel are files; stats report real lengths, modes and mtimes; /log streams
pane new/del/rename/save events. The tree code lives in src/ninep/
(tree, pane, ctl, addr, pty, events, screen, sources); fs.zig keeps host
access, mounts, resolution and find/grep. Same engine and transports.
README (fs-help.txt) and docs rewritten; tests updated and extended.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The tag's first character moved to TAG_TEXT_INSET when the grip's hit area was
separated from the text by a gap; the assertion kept reading GUTTER, which is
now the gap itself and carries the plain tag background. The test's own point —
that a preview on the tag's first character is paintable at tag column zero,
PREFIX_W being a body concern — is unchanged; only where column zero is moved.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In raw tty mode Alt-n reached the child as a bare `n`: the ESC prefix was
dropped on the floor, and only on macOS. ghostty's encoder refuses the legacy
alt-esc prefix on a macOS build unless macos_option_as_alt says Option really
is Alt, and KeyEncodeOptions.fromTerminal cannot know that one — it says so in
a comment — so it defaults to false.
False is right for an app that lets macOS translate the chord and hands the
encoder the composed text. Every pardes shell decides the modifier itself and
hands the core the BASE key with the alt bit and no text at all, which
PardesView.keyDown and app.mjs both spell the same way, so by the time the
encoder runs there is nothing left to translate.
The unit suite has been catching this on macOS all along; it is only invisible
on Linux, where that branch does not compile in.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A swipe that was still moving when the fingers lifted stopped dead. The dial
next to it has thrown properly since pardes_rotate_end, and this is that same
curve on the scroll accumulator: velocity sampled between events off the
monotonic clock, weighted toward the newest sample because a flick is decided
by how the hand was moving when it left, and a fling that ramps up from zero
at the floor rather than switching on at it.
A coast stops at the end of a document rather than spinning its remaining
velocity against the edge, which is why spendScroll now reports whether the
pane moved and why paneAt is public. Only a step that delivered a press can
report an edge — the many steps between two rows cross nothing.
Nothing suppresses AppKit's own momentum, and nothing needs to: its momentum
events are ordinary pardes_scroll calls, every one of which cancels the coast
before spending its travel, so on a real trackpad the system takes the gesture
over about a frame after the lift and the tail it ends on is below the floor.
This is the path for devices AppKit does not fling for — and the only one a
script can reach, since NSEvent phases have no public constructor.
momentum.snap asserts both halves, which is why it needs the long scrollback:
a flick with no document left proves nothing. A slow swipe is byte-identical
after the release; a hard one coasts twenty-four rows further on its own, and
a finger back on the pad stops it there.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The builtin was gated on the SDL platform, so the macOS shell never registered
it and the setting had nowhere to land. macOS already had transparency, but
only the binary kind a theme decides — a theme with no background of its own
drops the ground and the blur shows through. WindowOpacity is the graded,
theme-independent version, and the window had no way to hear about it.
pardes_window_opacity reports the percentage and acknowledges the request in
one read, beside pardes_theme_bg: an SDL surface can arrive without an alpha
channel and has to be able to refuse, while an AppKit window always composites
per pixel, so there is nothing here to refuse and no rollback to perform.
The view then paints the rule shaders/ui.frag.glsl states for the SDL shell:
backgrounds — ground, cell and band fills, and the chrome rules over them —
take the alpha, glyph ink never does, and the block cursor is exempt because
it is foreground chrome that happens to be carried in a cell background. That
exemption is why the cursor joins the colour in the background run key; it can
no longer share a fill with the cells beside it.
Two things the harness was missing fall out of testing it: it never adopted
the theme background or the opacity, so a Theme or WindowOpacity in a script
moved the core and never reached a pixel. draw-opacity records both ends of
the alpha range, which is what makes the two-sided contract assertable —
60% reads 153..255, and 0% reads 0..255 with the ink still standing.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tag text stopped living in the frame grid when the core moved the topbar, the
column bar and every pane tag into tag layers of their own; the grid keeps the
chrome and the physical grips. readFrame still read the grid alone, so every
capture recorded blank header rows and each script timed out waiting for text
that was on screen but not in the dump. Flatten the layers back over the grid
at one cell per column — the tty backend's spelling, which these goldens exist
to stay comparable with — and follow pardes_font_take to its size out-param.
The goldens were recorded before the column bar and before the tag gap, so
they are rerecorded here: the captures now agree column for column with what
the tty renderer paints today.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The body-layer context rules landed on a private TaglineMetrics.scale, which
never compiled: no macOS host built this shell when they were written. Expose
the physical-pixel thickness the way borderThickness/borderTop already expose
theirs, and paint the rule over the row's last pixel the way the SDL shell
does, so the two shells agree on the pixel rather than sitting one apart.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
