Show live progress while the TUI scans and deletes - #5
Merged
Conversation
The TUI froze during its two long operations because both ran on the UI thread: the delete loop and the scan were synchronous blocking calls, so event_loop never redrew. With large roots now reachable (e.g. /spacecraft-software, /), scanning could freeze the screen for seconds with no feedback. Move both operations onto a background worker thread (std::thread + mpsc; no new deps) feeding a progress overlay. Deleting shows a spinner, [done/total], 'freed X of Y', and a determinate Gauge; scanning shows a spinner naming the current category. The event loop pumps the channel each tick and animates at ~12fps (ACTIVE_TICK 80ms) only while a job runs — idle stays at 250ms. Esc cancels a deletion after the current item (cooperative AtomicBool) and quits during a scan (read-only thread safely abandoned); a finished delete auto- rescans. Scan errors are now surfaced in the overlay instead of aborting the TUI. Deletions remain bounded by the same roots + safety::check_deletable. Docs: Texinfo 'Interactive TUI' gains a Progress section; AGENTS.md and SKILL.md note the overlay. Adds a progress_ratio unit test (45 total). The live overlay needs a TTY and is not unit-tested; the pure ratio logic is. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The TUI froze during its two long operations — the delete loop and the scan both ran synchronously on the UI thread, so
event_loopnever redrew. With large roots now reachable (/spacecraft-software,/), scanning could freeze the screen for seconds with no feedback.This moves both operations onto a background worker thread (
std::thread+mpsc— no new dependencies) feeding a live progress overlay:[done/total]+ "freed X of Y" + a determinateGauge.esccancels after the current item (cooperativeAtomicBool), then it auto-rescans.escquits (the read-only scan thread is safely abandoned). Scan errors are now non-fatal — shown in the overlay instead of crashing the TUI.ACTIVE_TICK80 ms) only while a job runs; idle stays at 250 ms, so no extra CPU at rest.safety::check_deletable. The worker only movesSenddata (Candidate/Deleter/Outcome).Docs
AGENTS.mdandSKILL.mdnote the overlay.Testing
cargo fmt --check·cargo clippy --workspace --all-targets -- -D warnings·cargo test --workspace(45 pass — newprogress_ratiounit test) ·reuse lintcompliant ·makeinfozero-warning.~/.cargo/bin/vacuum.progress_ratiohelper. Worth a manual smoke-test:vacuum tui /spacecraft-software(scan spinner cycles categories); select large items →enter→y(gauge fills);escmid-delete cancels cleanly.Out of scope / follow-ups
remove_dir_all/jwalk(cancel is between items / between cleaners only).🤖 Generated with Claude Code