forked from 1b-agent/opencadstudio-upstream
buyun14
899af80c2f
`run_command_line` feeds the tokens after the command verb to the interactive command and then terminates it as if Enter were pressed. Two gaps left a headless caller unable to tell what actually happened. In-place text editor takes over, remaining tokens were dropped ---------------------------------------------------------------- The `TEXT` content step hands over to the in-place editor, at which point the command has already ended (`active_cmd` is `None`). The feed loop stopped there, so the rest of the line — including the text itself — vanished: `TEXT 0,0 5 0 hello` reported `completed` with `added: 0` and created nothing. The tail is now typed into that editor and committed, and the commit is done synchronously so its result is observable: `text_inline_commit()` returning false leaves the tokens in `unconsumed` instead of reporting a successful line. Dispatch the commit as a queued message instead and a failed commit would look exactly like a good one — the text dropped, `added: 0`, `unconsumed: []`. Only an editor this line opens is taken over, and after a successful commit the line is closed with an escape: `TEXT` re-arms for the next line (`open_next_line`), which would otherwise let the *next* batch line be eaten as the next text position. Leftover tokens are dropped --------------------------- Any token no prompt ever asked for is recorded in `CommandLine::unconsumed` and surfaced by the automation `run` response, so over-typed or misplaced input is visible instead of silently ignored: `CIRCLE 0,0 5 9` reports `"unconsumed": ["9"]` while a fully consumed line reports an empty list. Pending surfaces are reported instead of `completed` ---------------------------------------------------- `run` now carries `blocked_by` — `"command"`, `"text_editor"`, `"mtext_editor"`, `"modal:<Kind>"`, or `null` — and answers `waiting_input` when something is still open rather than claiming `completed`. `blocked_by` is attributed to the line that opened the surface: a condition and its snapshot are taken before the command runs, so an editor left open by an earlier line, another tab, or a startup dialog does not turn a finished command into `waiting_input`. Without that attribution a caller polling for `completed` would wait forever on someone else's editor. `docs/automation` documented `waiting_input` as "more input is required", which is exactly what a pending surface is; the two new fields are documented there as well. Tests ----- * `batch_text_line_creates_text_and_consumes_every_token` — the regression case creates exactly one `Text` entity and leaves nothing unconsumed. * `multi_word_text_keeps_the_spaces` — asserts the committed string, so an off-by-one in the consumed index or a wrong join cannot pass. * `run_reports_leftover_tokens_instead_of_dropping_them`. * `text_without_content_reports_the_open_editor`. * `a_stray_editor_is_not_hijacked_by_the_next_line` — the next line neither types into the stray editor nor inherits its blocker (`blocked_by: null`, `status: completed`). * `a_command_still_waiting_is_named_as_the_blocker`. Verified over the `--serve` protocol: `TEXT 0,0 5 0 hello world` → `completed`, `added: 1`, and the entity really holds `hello world`; `TEXT 40,0 5 0` → `waiting_input` + `blocked_by: "text_editor"`; the following `CIRCLE 0,0 5 9` → `completed`, `blocked_by: null`, `unconsumed: ["9"]`; `LINE` → `waiting_input` + `blocked_by: "command"`. Full lib suite: 1497 passed, 2 failed — both failures (`io::plot_style::…named_tables_and_missing_files_get_a_reason`, `scene::parametric_constraints::…arc_grips_drive_center_start_and_end_but_not_midpoint`) reproduce on the unmodified tree; run with `LC_ALL=C` since several xref tests otherwise fail on a non-English locale. Known remaining gap, unchanged here: `MTEXT` / `HATCH` still answer `completed` with `added: 0` in this path (they need interactive surfaces the feeder has no tokens to fill). Reported separately in #1390.
