fix(tui): replace standalone compacting label with animated working label

[donglovejava]

Summary

Compacting phase previously showed a static 'compacting' text in the footer status bar, while loading phase used the animated footer_working_label with elapsed seconds. This inconsistency made compacting appear to hang — users saw a static label with no visual feedback during long compaction turns.

Changes

Consolidated both phases to use the unified footer_working_label with elapsed seconds, so compacting now shows the same animated dot-pulse and timer as loading. Removed the dead else-if branch that always returned footer_working_label regardless of which path was taken.

Verification

• cargo check -p codewhale-tui — passes
• Footer UI tests pass
• Shell interaction tests pass

Related

This continues the feedback improvements from #2166.

Greptile Summary

This PR consolidates the footer status label logic during active turns: instead of a static "compacting" string for the compacting phase versus an animated footer_working_label for loading, all active phases now use the unified animated label with elapsed seconds. The dead else branch (which already called footer_working_label) is also eliminated.

• The three-way if is_loading / else if is_compacting / else conditional in render_footer is replaced with a single unconditional call to footer_working_label, giving users the same animated dot-pulse and (Xs) timer feedback during compaction as during model loading.
• Compaction-specific text ("compacting context") is still surfaced via stall_reason after 30 seconds, so long compactions remain identifiable.
• A trailing newline was incidentally dropped from the end of the file.

Confidence Score: 4/5

Safe to merge; the logic change is small and intentional, with the only unintended edit being a dropped trailing newline.

The code simplification is correct — both the is_loading and else branches were already calling footer_working_label, so the only real behavioral change is replacing the static "compacting" string with the animated label. footer_working_strip_active already gates on is_compacting, so the strip stays visible throughout compaction. The sole nit is the missing newline at EOF introduced alongside the logic change.

No files require special attention beyond the trailing-newline nit in footer_ui.rs.

Important Files Changed

Filename	Overview
crates/tui/src/tui/footer_ui.rs	Simplified the working-state label: removed the if is_loading / else if is_compacting / else chain in favour of always calling footer_working_label, so animated dot-pulse and elapsed-seconds timer are shown uniformly during all active phases. A trailing newline was also inadvertently dropped from the file.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[render_footer called] --> B{footer_working_strip_active?}
    B -- No --> C[Check for selected_detail_footer_label]
    B -- Yes --> D[active_subagent_status_label?]
    D -- Some --> G[Use subagent label]
    D -- None --> E[active_tool_status_label?]
    E -- Some --> G
    E -- None --> F["footer_working_label(dot_frame, locale) + elapsed_secs if > 0\n(BEFORE: static 'compacting' string for is_compacting)"]
    F --> H{stall_reason elapsed > 30s?}
    H -- Yes --> I[Append: 'compacting context' / 'waiting for model' / etc.]
    H -- No --> J[Set state_label + animate strip]
    I --> J

Loading

_{Reviews (1): Last reviewed commit: "fix(tui): replace standalone compacting ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[greptile-apps]

The trailing newline was removed from the end of the file. Most Rust formatters (rustfmt) and editors expect a newline at EOF; its absence can produce diffs on every subsequent rustfmt run and may trigger linting warnings in CI.

Suggested change

	spans.iter().map(|span| span.content.width()).sum()
	}
	}
	spans.iter().map(|span| span.content.width()).sum()
	}

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!