Expand dor CLI commands#121
Conversation
Deploying mouseterm with
|
| Latest commit: |
d257ced
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://181ff992.mouseterm.pages.dev |
| Branch Preview URL: | https://cli-expanded.mouseterm.pages.dev |
dormouse-bot
left a comment
dormouse-bot
left a comment
There was a problem hiding this comment.
A couple of observations from the new dor read command:
dor read --scrollback returns raw PTY bytes (with ANSI escapes), not clean text. The scrollback path in Wall.tsx calls getPlatform().getScrollback(...), which returns the joined scrollbackChunks from vscode-ext/src/pty-manager.ts and standalone/sidecar/pty-core.js. Those chunks are the raw byte stream (color codes, OSC sequences, cursor moves) kept so session-restore can faithfully reproduce the terminal — not human-readable history. By contrast, the default (visible) path uses translateToString(true) and returns clean text. So dor read --scrollback | grep TODO will see garbled lines and --lines N will trim by raw \n count rather than rendered lines. The test fixture hides this because it hands back pre-cleaned strings.
An xterm-buffer-based read (iterate buffer.getLine(i).translateToString(true) over 0..buffer.length, then take the visible slice or all of it depending on --scrollback) would give consistent clean text and a consistent --lines semantic across both modes.
dor read text mode emits no trailing newline. readVisibleSurfaceText strips trailing newlines with .replace(/\n+$/, '') and renderReadResponse returns the text as-is, so the next shell prompt lands on the same line as the last terminal row. Intentional, or worth a final \n from the renderer like the JSON case?
# Conflicts: # dor/package.json
The await-user path used window.confirm(), which a Tauri webview doesn't support synchronously — it returned false instantly, so the command ended immediately as "kill was not confirmed" and the dialog never opened. Open the existing in-app kill dialog instead and block the control request until the user accepts (matching letter) or rejects (Esc/any other key/ dismiss), wiring acceptKill/rejectKill to resolve the pending promise plus a safety net that resolves false if the dialog is dismissed by another path. A human-paced confirmation also outlasts both deadlines guarding the request, so disable them for await-user kills: the dor client passes no timeout, and the control server skips its safety-net timer (with a socket-close handler to release the now-unbounded pending entry if the client disconnects). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The await-user mode blocked the CLI call on a human answering an in-app modal, but the interaction model doesn't hold up: a CLI invocation hanging indefinitely on someone noticing a modal somewhere on screen — with no mechanism to route attention to it — is the wrong primitive. The kill-confirm dialog was also gated behind the Wall's command mode, so the confirm letter never reached it from a terminal in passthrough mode anyway. The remaining modes cover the real programmatic needs: --confirm-dangerously (unconditional) and --confirm-if-read (guard on visible text). A proper human-in-the-loop kill would need a non-blocking, attributed notification channel; build that if a consumer actually needs it. Reverts the await-user wiring across the CLI flag/parser, request types, control client timeout handling, and the webview handler. Keeps the control server's socket-close cleanup, which is a standalone correctness improvement. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 participants
Summary
Tests
Stacked on #120 / add-dor-cli.