`convert` and `run --export` always fitted the model-space extents, so
`zoom`, `pan` or `view.set` in a run had no effect on the image and there
was no way to export a region.
- io: `write_framed(d, name, window)` frames PNG, SVG and PDF on a
model-space rectangle (fitted without margin, centred, no distortion);
`write` is unchanged and still fits the extents. `check_window` rejects
non-finite, inverted, zero-size and out-of-range (±1e12) windows.
- CLI: `run --export` shows the current view when the commands changed
it, otherwise the extents as before. `--window x0,y0,x1,y1` and
`--view extents|current` on `convert` and `run` choose the framing
explicitly. The usage text and README say how images are framed.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* cadcraft-cli mcp: --connect without HOST:PORT is an error, not a headless session (#103)
`mcp --connect` with no address (or an empty or flag-like one) fell through
to the headless backend, so a client meant for the app got successful edits
in a separate drawing. The mcp arguments now go through parse_mcp_args:
--connect must be followed by a non-empty value that doesn't start with `-`,
unknown arguments and a repeated --connect are rejected, and every error
exits non-zero before any MCP request is served. Plain `mcp` is still
headless; a real address still connects, and an unreachable one still fails.
- Unit tests for the parser; integration tests (tests/mcp_connect.rs) run the
binary: missing/empty/flag-like address, headless control, loopback
endpoint routing, closed port.
- docs/mcp.md says what happens without an address.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Move tests away from other PRs' hunks to avoid merge conflicts
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
TAN and PER snaps need the other end of the line, so the first point of a
LINE (no base point yet) could never snap tangent: a belt line tangent to
two circles was impossible to draw.
Now, as in AutoCAD, a point prompt can accept *deferred* snaps:
- snap: with no base and the new `deferred` flag, osnap offers "Deferred
Tangent" (circles, arcs) and "Deferred Perpendicular" (circles, arcs,
lines, xlines, rays) where no other snap wins. The hit carries the curve
(`SnapHit::deferred`, `Deferred`, `SnapCurve`).
- `resolve_deferred` solves the line once the other end is known: tangent
or perpendicular from a point, tangent-to-tangent (common tangents of two
circles, new `Circle::common_tangents` in geom) and the perpendicular
mixes. Among several solutions the one nearest the picks wins. No
solution (point inside the circle, concentric or nested circles,
non-finite input) is `None`, never a panic.
- prompt: `Prompt::deferred()` opts a prompt in; `Input::Deferred` reaches
only such prompts, everywhere else the session turns it into the point it
was picked at, so other commands snap as before.
- LINE opts in for its first point (and the next one while the first is
still deferred). No solution reports and re-prompts; Undo drops the
deferred point. The rubber band shows the resolved line, also the
tangent-to-tangent one while hovering the second curve
(`Session::cursor_deferred`, set by the canvas).
- canvas: passes the prompt's flag to osnap and sends a deferred pick as
`Input::Deferred`.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A pick after one edit at 200k entities drops from ~110 ms (full rebuild) to ~4 ms;
steady-state picks stay at ~1 us. Adds a parity test against fresh builds and a
perf row for the incremental path.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>