remove em-dash from TODO
This commit is contained in:
parent
1f2b6b32de
commit
fd8748e55e
1 changed files with 0 additions and 48 deletions
48
TODO.md
48
TODO.md
|
|
@ -328,54 +328,6 @@ cosmetic label. Worth it once we want trustworthy timestamps (e.g. for
|
|||
screenshots, or to stop conflating "live" with "last close"); not
|
||||
before.
|
||||
|
||||
## Audit: em-dash sentinel usage across all tables - priority LOW
|
||||
|
||||
The codebase uses `-` (em-dash) as the canonical "no data" sentinel
|
||||
in several table cells, but the rendering rules and alignment
|
||||
choices are inconsistent. AGENTS.md now warns against em-dash
|
||||
overuse generally; this audit is the second half - pick a
|
||||
consistent treatment and apply it everywhere.
|
||||
|
||||
Known em-dash sites:
|
||||
|
||||
- `src/views/projections.zig` (back-test): hard-coded `dash_cell`
|
||||
literal in 10-col cells - pre-shaped at compile time so no
|
||||
helper is involved. Numeric cells use Zig's `{s:>10}` byte-
|
||||
padding (safe since they're pure ASCII).
|
||||
- `src/commands/history.zig` / `src/tui/history_tab.zig`: centered
|
||||
via `fmt.centerDash` in 31-col cells (illiquid totals on
|
||||
imported-only history rows).
|
||||
- `src/commands/milestones.zig`: right-padded via
|
||||
`fmt.padRightToCols` in the "days since prev" cell. Mixes
|
||||
with ASCII cells like `"42 days"`.
|
||||
- `src/commands/perf.zig` / `src/tui/performance_tab.zig`:
|
||||
emitted via `{s:>13}` byte-padding - under-padded by 2 cols
|
||||
per em-dash. Either hard-code a `dash_cell` literal (cell
|
||||
width is static) or migrate to `fmt.centerDash` /
|
||||
`fmt.padRightToCols`.
|
||||
|
||||
Decisions to make:
|
||||
|
||||
1. **Centered vs right-aligned in numeric columns.** Back-test
|
||||
centers; perf right-aligns (or would, if it weren't broken).
|
||||
Centering reads as a more deliberate sentinel; right-aligning
|
||||
keeps the visual right-edge of the column smooth. Pick one.
|
||||
2. **Should some tables drop the em-dash entirely** in favor of
|
||||
ASCII `-`? Rule of thumb: if the column header makes the
|
||||
meaning unambiguous AND no rows contain bare `-` for other
|
||||
reasons (signed values use `-2.21%` which is multi-char, so
|
||||
a lone `-` is unambiguous), `-` is fine. If the column also
|
||||
carries dates or strings where a stray `-` could read as
|
||||
part of the value, keep `-`.
|
||||
3. **Helper vs literal.** When the cell width is fixed and the
|
||||
dash position is static, a hard-coded literal const string
|
||||
(like back-test's `dash_cell`) is simpler than calling a
|
||||
helper at runtime. Use helpers when width or position varies.
|
||||
|
||||
Once decisions are made, sweep all four sites + add a regression
|
||||
alignment test per table that mixes a fully-populated row with
|
||||
an em-dash-heavy row and verifies `displayCols` matches.
|
||||
|
||||
## Analysis: dividend equity / income-shaped equity - think about it
|
||||
|
||||
Dividend-equity ETFs (SCHD, VYM, DGRO, NOBL, SDY, VIG, etc.)
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue