Edit runs acme's file and shell commands: < | > 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

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 7 insertions, 0 deletions

diff --git a/src/9p_io.zig b/src/9p_io.zig
index 68f6f6b7..671a1852 100644
--- a/src/9p_io.zig
+++ b/src/9p_io.zig
@@ -268,6 +268,9 @@ pub const Listener = struct {
         const changes = pardes.ctlfs.changesPane(core, req);
         const fills = pardes.ctlfs.handsOff(core, req);
         const reply = core.serveFs(req);
+        // Taken now: a request served while this one waits starts afresh.
+        const edit_at = core.fs.edit_answer_at;
+        core.fs.edit_answer_at = null;
         if (req.op == .release and quiet) l.collectOs();
         // A close's held last line runs now when no step is out, so its err
         // is logged before the close is answered, as before; with a step
@@ -346,6 +349,10 @@ pub const Listener = struct {
                 }
             };
         }
+        // An Edit whose `<`, `|` or `>` commands run off the loop: the write
+        // is answered once they have and the Edit is applied, or failed
+        // (late_failure), as `echo Edit , | sort > ctl` must return sorted.
+        if (edit_at) |n| if (l.core == core) pardes.turn.awaitEdit(n);
         core.fs.write_waits = false;
         // ponytail: one slot, so a failure of another client's effects that
         // settle in the same wait is told to this write too.