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
|
screenshots, or to stop conflating "live" with "last close"); not
|
||||||
before.
|
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
|
## Analysis: dividend equity / income-shaped equity - think about it
|
||||||
|
|
||||||
Dividend-equity ETFs (SCHD, VYM, DGRO, NOBL, SDY, VIG, etc.)
|
Dividend-equity ETFs (SCHD, VYM, DGRO, NOBL, SDY, VIG, etc.)
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue