feat: configurable numeric precision (per-widget, type-aware, optional global)

[zachthedev]

Closes #455

Replaces the rejected "always trim .0" approach (per the discussion here) with
configurable decimal precision for numeric widgets. Default output is unchanged.

Model

• Per-widget numberFormat: { style?, decimals? } (top-level WidgetItem field,
  alongside dim/bold):
  • style: precise (keep trailing zeros, today's 1.0M) | compact (trim
    them: 1M, 1.1M) | whole (no decimals: 1M).
  • decimals: max places before style applies.
• Optional per-kind global Settings.numberFormat (token, speed, percent,
  memory, cost). A kind set there wins over the per-widget value, same
  precedence as overrideForegroundColor / globalBold.
• Type-aware baselines, so a token-oriented change never pulls money off two
  decimals: token/speed/percent default 1, cost 2, memory G:1 / M:0 / K:0.
• resolveNumberFormat(kind, item, settings) is the single choke point; the
  pure formatters (formatTokens, formatSpeed, formatPercent, formatCost,
  memory) take the resolved format. Optional fields, so no settings migration.

Scope

Every numeric widget: tokens in/out/cached/total, context length/window/bar,
compaction reclaimed, cache read/write/hit, free memory, session cost,
input/output/total speed, context %/usable, the usage sliders (session, weekly,
weekly opus/sonnet, extra-usage), and the block/weekly timers.

TUI

• Color menu: (n) cycles the highlighted widget's style (default -> compact ->
  whole); reset / clear-all also clear it.
• Global overrides: (n) opens a per-type submenu to cycle each kind's style.
• decimals is set per-widget / per-kind in settings.json (the power-user
  axis); the TUI exposes the style.

Tests

bun run lint clean; bun test green (1577). Default output is unchanged
(every existing widget/formatter assertion still passes); added coverage for the
format primitives, resolver precedence, and the TUI style cycle.

[CorticalCode]

@zachthedev

Hi, I wanted to advocate for leaving the decimal point in place. At first glance I figured yeah, that trailing zero shouldn't be there. But thinking about it, on a live status line it's actually doing a job: it holds the field width steady as the number climbs. Drop it and the width snaps every time the count crosses a whole unit (1M, then 1.1M, and so on), which ends up more distracting than the .0 it removes.

Claude Code keeps follows this behavior in its token count: past 999 the decimal is preserved through the zeros (e.g. 6.0k, not 6k).

[zachthedev]

@zachthedev

Hi, I wanted to advocate for leaving the decimal point in place. At first glance I figured yeah, that trailing zero shouldn't be there. But thinking about it, on a live status line it's actually doing a job: it holds the field width steady as the number climbs. Drop it and the width snaps every time the count crosses a whole unit (1M, then 1.1M, and so on), which ends up more distracting than the .0 it removes.

Claude Code keeps it too in its token counter: past 999 the decimal is preservedthrough the zeros (e.g. 6.0k, not 6k).

That is a good point, it should be configurable honestly. I am going to rework it to be a per element or global config to have decimals or not. Instead of chopping off .0.

[sirmalloc]

@zachthedev i prefer this be a widget specific config, not global.

[zachthedev]

@zachthedev i prefer this be a widget specific config, not global.

What about widget specific with a global override? If a user didn't want to manually configure every one.
Default would be as it is nowadays.

[sirmalloc]

@zachthedev i prefer this be a widget specific config, not global.

What about widget specific with a global override? If a user didn't want to manually configure every one. Default would be as it is nowadays.

What widgets would it impact? Anything displaying a number? It'll touch more widgets but if it makes sense I'm fine with it if it's done cleanly and doesn't modify existing default behavior.

[zachthedev]

@zachthedev i prefer this be a widget specific config, not global.

What about widget specific with a global override? If a user didn't want to manually configure every one. Default would be as it is nowadays.

What widgets would it impact? Anything displaying a number? It'll touch more widgets but if it makes sense I'm fine with it if it's done cleanly and doesn't modify existing default behavior.

Yeah anything displaying a number. I marked this as a draft and will mess around with a few ideas.