fix: widen process list TIME+ column to prevent Command drift#151
Merged
Conversation
The TIME+ column was fixed at 8 chars, but format_cpu_time can produce
values up to 10 chars ("8760:00:00" at the 365-day cap). Values like
"213:16:04" (9 chars) overflow the column and push the Command column
right, so rows with 9-char times no longer align with the header or
with rows that have shorter times.
Widen fixed_widths[11] from 8 to 10 so all possible TIME+ values
right-align cleanly in the column and Command stays at a consistent
position. Document the width invariant in format_cpu_time and add a
regression test that enforces the maximum output width.
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
Fixes misalignment between the
TIME+andCommandcolumns in the process list (view mode), where rows containing TIME+ values of 9+ characters push the Command column to the right and break alignment with the header and with rows that have shorter times.Root cause
src/ui/process_renderer.rssetsfixed_widths[11] = 8for the TIME+ column, butformat_cpu_timecan produce values up to 10 characters long ("8760:00:00", hitting the 365-day cap). Values like"213:16:04"(9 chars),"194:49:38"(9 chars),"100:18:34"(9 chars) all overflow the 8-char column.The format specifier
{time_plus:>time_w$}is a minimum width, not a maximum — when a value is longer thantime_w, it expands and pushesCommandright. Rows with 7-char times (e.g.," 1:22:59") get padded to 8, but rows with 9-char times expand by 1. This compounds inprint_process_row_coloredwherecurrent_pos = col_endis computed assuming no overflow, sooutput_pos(actual rendered position) drifts from the logical column grid.Fix
fixed_widths[11]from 8 to 10 so all possible TIME+ values right-align cleanly in the column, keeping Command at a consistent position across header and every row.format_cpu_timeso future changes to the output format are aware of the column-width dependency.test_format_cpu_time_max_width_fits_time_columnthat enforces the invariant: every boundary value from 0s to 365 days must fit within the 10-char column. If the cap is ever lifted or the format changes, this test will fail loudly.Test plan
cargo test --lib(211 passed, including the new regression test)cargo clippy --lib(clean)cargo fmt --check(clean)"8760:00:00"= 10 charsBefore / after
Before (from the reported screenshot):
213:16:04(9 chars) overflows the 8-char column, pushing[privatecloudcomputed]one column right of[claude].After:
All TIME+ values right-align within the 10-char column and Command starts at the same position on every row.