<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pardes.git/src/fs.zig, branch main</title>
<subtitle>Pardes</subtitle>
<id>https://git.0x4200.cafe/pardes.git/atom?h=main</id>
<link rel='self' href='https://git.0x4200.cafe/pardes.git/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/'/>
<updated>2026-10-02T02:22:39Z</updated>
<entry>
<title>Round 39's small ones: a name write past its one line is refused by that write; Get and Edit's e load over a scratch under 100 bytes unasked, as Del closes it; Putall saves a Zerox pair once; bare Tab on the root ctl says the width as from a pane, and a ctl check of Tab no longer sets it; a directory read is "is a directory" (EISDIR), an unreadable file "permission denied" (EACCES), Incl of a file "not a directory" (ENOTDIR), and a device "not a regular file", never read to the stream limit</title>
<updated>2026-10-02T02:22:39Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-02T02:20:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=dd6a3c2c367cee12a8e2da81e7da6a2c8f3103d5'/>
<id>urn:sha1:dd6a3c2c367cee12a8e2da81e7da6a2c8f3103d5</id>
<content type='text'>
Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>An Edit's held write: &lt; | &gt; commands no longer block their 9P connection (answered like a held read, so a status read or a filter reading the session's own mount runs beside it), a Tflush or hang-up of the write kills the commands' process groups and changes nothing; e loads by Get's way (asked once, clean after, undo puts the name back); ~ in e r w f B; B checks every name first; an Edit that runs commands is a write of its own, refused up front with other lines; Edit's +Errors output keeps the keyboard where it was; X goes in pane order; a refused write open says its errno; the reference's Coming from acme rows say what Get file's undo, failure and directory refusal, Putall's answer, Zerox across Dump and Incl's directories now do</title>
<updated>2026-10-02T01:07:48Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T23:50:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=406f483288c7689bdd2e1f3f68b276c61ca9412a'/>
<id>urn:sha1:406f483288c7689bdd2e1f3f68b276c61ca9412a</id>
<content type='text'>
Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Edit runs acme's file and shell commands: &lt; | &gt; through the session's Shell off the loop (one undo step, a failure changes nothing, its stderr in +Errors, a 9P write answered when done), X and Y over the open text panes, b B D e r f w and the "file" address; checked against sam -d, and the reference's Edit section and Coming from acme row say so</title>
<updated>2026-10-01T23:04:42Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T20:43:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=805b9f188768fee523d462411d846912e0877ff3'/>
<id>urn:sha1:805b9f188768fee523d462411d846912e0877ff3</id>
<content type='text'>
Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>`&gt; exec` through a mount no longer hangs the editor, and a close holding a last line is answered at once: the line runs at the editor's next step</title>
<updated>2026-10-01T14:09:59Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T13:45:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=c5e5db988e59689b44feb42c59090c07687bcd42'/>
<id>urn:sha1:c5e5db988e59689b44feb42c59090c07687bcd42</id>
<content type='text'>
A shell's truncating open of exec (or look, ctl, log, pager) sends a
setattr that changes nothing; it waited for the editor to be quiet, and
through a 9ns mount that quiet could never come: 9ns answers nothing else
on the mount while the setattr is out, and the editor's step may be out
reading a pane's file through it. This was the "truncating open of exec
hangs, only in selfmount" mystery. Only a truncate of a pane's file or a
tag waits now.

A close holding a last line with no newline hands it to the editor's step
(tree.runClosedLines, beside fillClosedPagers), as a /pager close does, and
is answered at once; a refusal is the log's err.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A +Pager keeps its program's colours: the session parses what /pager is written after its directory with ghostty-vt, SGR becomes spans drawn over the plain text, every other escape is dropped, and PagerColor off pages it plain</title>
<updated>2026-10-01T13:36:28Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T13:09:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=edad6d960dc0fc1165cbb3b801e0538045b2247f'/>
<id>urn:sha1:edad6d960dc0fc1165cbb3b801e0538045b2247f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Grep and Find say when a cap hid what they might have found: `cut at 512 hits`, `N files read only in part (first 256 KiB)`, `walk cut at N entries`; one that finds nothing leaves the +Search as it was</title>
<updated>2026-10-01T11:53:11Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T11:15:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=a274bd2c706fdfd3effa0ad88c5b4083c0dc0f33'/>
<id>urn:sha1:a274bd2c706fdfd3effa0ad88c5b4083c0dc0f33</id>
<content type='text'>
Grep reads 256 KiB of a file and stops at 512 hits, and its walk at
20000 files or 100000 entries; Find stops at 512 names. A cap hit was
silent, so a match past one read as `pattern not found`. The walk now
notes each cap it hit (fs.WalkNotes) and the +Search says it in a line
under the hits, as it says directories skipped; a search that found
nothing but hit a cap opens the +Search with those lines, not a miss.
A Find or Grep that finds nothing and passed nothing over leaves the
directory's +Search with the last search's rows, its failure saying so,
where it used to empty it.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A Rename that previews other files answers its preview pane to the 9P write that asked it, and says on the message row that it previewed and applied nothing</title>
<updated>2026-10-01T10:16:43Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T09:22:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=fb330ce04c4eec4de317637d26310b74e2ee5923'/>
<id>urn:sha1:fb330ce04c4eec4de317637d26310b74e2ee5923</id>
<content type='text'>
A multi-file Rename filled a +Search preview but the waiting exec write
answered the pane it was asked from, and nothing was said. lspResponse
now notes the pane it filled (fs.lsp_result); the write that waited for
the answer reads that pane back, as a look or an exec answers the pane
it went to, and the message row says `Rename: N edit(s) across files,
previewed, not applied`.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>Grep and Find pass over a directory they may not open and keep every other hit, saying in one line how many they skipped</title>
<updated>2026-10-01T10:16:43Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T09:17:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=df10c37122cc3e6565d13aeefb9466dc6c0dc780'/>
<id>urn:sha1:df10c37122cc3e6565d13aeefb9466dc6c0dc780</id>
<content type='text'>
One `chmod 000` directory anywhere under a pane made every Grep say
`pattern not found` and every Find `access denied`: the walk's `try
w.enter`/`try w.next` ended it at the first refusal. Each is now counted
and passed over, and the +Search ends `N directories skipped:
permission denied` under the hits.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A name under a directory that may not be searched or written is refused, permission denied, and a Save there says so, not no such directory</title>
<updated>2026-10-01T08:18:09Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T08:01:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=250db41743f77ce3d8421f729bdea0065aa6bc79'/>
<id>urn:sha1:250db41743f77ce3d8421f729bdea0065aa6bc79</id>
<content type='text'>
`pardes noperm/a/b/c` and `pardes /proc/1/root/x` took the missing
directory for one Save would make, opened a pane and exited 0; its Save
then said "no such directory". fs.deniedAbove finds the nearest
directory there and asks whether it may be searched and written:
forwarding refuses such a name, exit 1, "permission denied", and a
failed Save says "permission denied", which the writer's 9P error
carries as EPERM (9ns: EACCES).

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>A log follower hears every record queued before a Restore: the read it holds takes all that fit, before the hangup cuts it</title>
<updated>2026-10-01T06:04:35Z</updated>
<author>
<name>Gabriel Schneider</name>
<email>gbrls@0x4200.cafe</email>
</author>
<published>2026-10-01T06:04:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0x4200.cafe/pardes.git/commit/?id=422ad65025edd994b04728632fc96de4ebda07f7'/>
<id>urn:sha1:422ad65025edd994b04728632fc96de4ebda07f7</id>
<content type='text'>
A follower reads one record per read, and a Restore hangs every client
up, so records queued just before it -- the ones a script most wants,
what led up to the Restore -- were lost: the read after the first was
cut. Before the cut, each held read of /log is answered with every
whole record queued that fits it.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
</feed>
