tui for headless ida https://git.sl0p.foo/ida-tui.git/atom/tools/demo.py?h=main 2026-08-07T14:23:24Z 2026-08-07T14:23:24Z blasty blasty@local 2026-08-07T14:23:24Z urn:sha1:0b81d7ac6efdc2715d0366d3aea6e092701d3a50 Manual navigation is snappy; the demo was not, because I authored the pauses for someone reading every status line. Halved every beat with a 0.25s floor so the scenes stay distinguishable, and dropped the prompt typing from 45ms to 18ms per character -- still legibly typing, no longer something you wait on. --speed still scales it either way: 0.5 for a fast cut, 2.0 to slow it back down for a narrated take. 2026-08-07T14:18:17Z blasty blasty@local 2026-08-07T14:18:17Z urn:sha1:a40bebf96c99c24a6965f297fcc6d7bb1cdf7599 The app auto-lands on main once the function index is in, so scene_open typed a goto to a place it was already standing. Every keystroke a driver injects costs a round trip, so that was pure dead time at the very start of the tour -- the worst place to spend it, since it is the part a recording opens on. 2026-08-07T13:53:53Z blasty blasty@local 2026-08-07T13:53:53Z urn:sha1:08b471dbdba30e4664a74f74fb3998afa879ea3b --spawn needs tmux or zellij and puts the app in a second pane, which is wrong when the capture is one terminal. --here launches the TUI through the ./ida-tui launcher with stdio inherited, so it draws on the terminal you ran the demo from, then drives it over the socket exactly as before and quits it at the end. Going through the launcher rather than re-deriving the interpreter keeps the $IDATUI_PYTHON rules in one place. Two things this mode has to get right: - Narration would be drawn over the app, so it is collected and replayed after the alternate screen is gone. The operator still sees the full scene list, just at the end instead of during. - The socket is waited for with a deadline that also watches the child, so a TUI that dies before it ever listens fails in a second instead of hanging until the timeout. Teardown reaps the process (wait, then terminate, then kill) and removes the scratch copy on every path. --here and --spawn are rejected together. Verified: argument handling, the mutual exclusion, and that the pure suites are unaffected. The end-to-end --here run is NOT verified here -- it needs a real terminal, which this environment does not have. 2026-08-07T13:51:00Z blasty blasty@local 2026-08-07T13:51:00Z urn:sha1:8887549473c1177619da9088d406792009e72f39 Ten scenes over the RPC layer: goto, listing scroll, pseudocode, the literal format ring, follow/back, the graph (zoom, minimap, edge walking), split view, xrefs, a rename and a comment, the strings/symbols/structs/hex browsers, and search. It drives the semantic verbs, so prompts are typed character by character and a recording shows the app being used rather than poked. --spawn opens its own pane on a COPY of the target (binary plus .i64, so the analysis is not re-paid) and tears it down afterwards; --sock drives a session you set up yourself, for control over pane size and zoom. Edits are reverted at the end, including a re-navigate so the last frame does not still show the demo's rename. --speed scales every pause, --only runs a subset, --list prints the scenes. Writing it found a real bug in the RPC hex verb: it waited for `app.is_hex` to become true, but backslash TOGGLES the hex view, so the call that leaves hex could never satisfy its predicate and always timed out after 20s. Any driver could open the hex view and never close it. It now waits for the mode to flip, the way toggle_view already did. Verified by running every scene against a live database and asserting the UI actually moved -- landed on main, decomp reachable, graph reports 280 blocks, split toggles off, no modal left open, the rename reaches the database and the revert removes it. 15/15. Full suite still 788 passed, 0 failed.