Skip to content

Command queue: prepare the next commands while one runs - #357

Draft
raiseCatError wants to merge 7 commits into
feature/input-awarenessfrom
feature/command-queue
Draft

raiseCatError wants to merge 7 commits into
feature/input-awarenessfrom
feature/command-queue

Conversation

@raiseCatError

Copy link
Copy Markdown
Owner

Stacked on #348 (input awareness). Part of the workflow initiative (ledger: docs/development/workflow-initiative-ledger.md on the copy branch).

What

While a command runs, Enter adds the composer's command to the session's queue (Ctrl+Q always queues, Ctrl+S sends the line to the running program). Entries run one at a time in the same shell, each after the previous command reached its prompt, so cwd, variables, functions and options carry over. A failure, Ctrl+C or a shell switch pauses the rest with the reason; /queue resume / /queue clear act; /queue opens a manager (edit, reorder, remove, pause).

Safety

  • The queue lives in the session service: it runs while detached; exec events say which command came from the queue, so a later window shows "from queue" too.
  • Input ownership first: a program known to wait for input, or one that left a question open on its line before any probe looked, gets Enter. Replies are never queued or run.
  • After Ctrl+C/Ctrl+Z, typing is type-ahead for the shell prompt for 2 s only; a program that survives the signal gets normal routing.
  • Ctrl+Q compose mode never leaks keys or Enter to the program.
  • Queue text is drawn with control characters made visible (no escape injection).

Tests

  • tests/commandQueue.test.ts (dispatcher, ordering, exactly-once, attribution, hostile text), protocol samples.
  • tests/commandQueueLive.test.ts: 13 real-PTY tests over zsh/Bash/Fish: ordering and state, failure/interrupt pauses, prompts and hidden replies, Ctrl+Q compose, Ctrl+Z/Ctrl+C type-ahead, a SIGINT-surviving program, multi-line paste, detach/reattach, narrow/NO_COLOR/Safe glyphs.
  • Full npm run verify locally: green when the machine is idle (an earlier run under heavy parallel load showed startup/service timeouts that pass 65/65 in isolation).

Not in this PR

Paste batches → queue, queue conditions (#354, #355).

…order in the same shell

While a command runs, Enter adds the composer's command to the session's queue (Ctrl+Q always queues,
Ctrl+S sends the line to the running program). Entries run one at a time through the session's own
shell, each only after the previous command reached its prompt, so directory, variables, functions
and options carry over. A failure, Ctrl+C or a shell switch pauses the rest with the reason;
/queue resume continues and /queue clear drops them, and nothing runs twice.

- The queue belongs to the session service (in-process client alike): it keeps running while no
  window is attached, and the exec event says which command came from the queue, so a window that
  attaches later shows "from queue" for it too.
- Input ownership first: a program known to wait for input, or one that left a question open on
  its line ("Password: ", "Continue? [y/N] ") before any probe looked, gets Enter; a reply is never
  queued or run as a command. After Ctrl+C or Ctrl+Z, typing goes to the shell prompt as type-ahead.
- Ctrl+Q during single-key input composes an entry the program never sees; Enter adds it.
- /queue opens a manager to edit, reorder, remove, pause and clear; the queue line by the composer
  shows what runs next or why it waits. Settings, Setup, Ask and settings export know about it.
- Live tests over zsh, Bash and Fish: ordering and state, failure and interrupt pauses, prompts,
  hidden replies, multi-line entries, detach and reattach, narrow/NO_COLOR/Safe glyphs. A live
  start that never becomes ready now ends its sandbox instead of hanging the test file.
Entry previews, pause reasons and the panel's block preview show control characters visibly (␛, ·)
instead of writing them to the terminal: a pasted OSC 52 or screen clear inside a queued command
can no longer act on the host terminal.
…the rest of the command

Typing after a stop goes to the shell prompt only for two seconds. A program that survives the
signal (a REPL, a remote shell, a trap) gets the ordinary routing again, so later typing queues as
usual and is never written into that program's input unasked.
…er-read files so shards do not stack them

These files take 17 to 68 seconds each but counted as 1, so a shard could run several heavy PTY files together on a 4-core runner and starve the timing-sensitive Fish and alternate-screen tests (17 to 24 second budgets), which then failed only on Ubuntu from this branch up.
…xt command only once the last one completed

With the queue, Enter while a command runs and nothing asks a question queues the next command. These tests typed their answer as soon as the command's own echo contained the prompt text (it does), or typed the next command before the previous one had completed, so on a slower runner the answer or command was queued instead of sent. They now wait for the program's own prompt (the second occurrence of its text, or NMSh's waiting headline) and for the previous completion.
…he command text NMSh echoes

In Classic wording NMSh's live line reads "Running read -P 'Name: ' x…", so waiting for "Name: " (or a second copy of it) was satisfied by NMSh's own line before Fish drew anything, and the answer was typed too early. The prompt is now produced by printf inside the command, so the text only appears when the shell prints it.
…ng command or the type-ahead window early

The first test queued five commands behind sleep 3 and the Ctrl+C test typed 0.6 seconds after a 2 second type-ahead window; on a loaded macOS runner either margin was lost and the typing was treated as type-ahead or the queue had already started.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant