Description
The Tools > Options > Statistics Parser page currently lists all 7 settings as
a flat list. As options have accumulated, the page is hard to scan and there's
no obvious home for new settings. Group the options into three subcategories.
Use case / motivation
A flat list of unrelated toggles is harder to navigate than a grouped one, and
the page will only get worse as more options land. Subcategories make the
options page self-documenting (the group names communicate what each setting
affects) and give future options an obvious bucket.
Proposed solution
Three Unified Settings subcategories under Statistics Parser:
- General
- Display
- Font Size
- Banded Rows
- Hide All-Zero Columns
- Temp Table Names
- Convert Completion Time to local time
- Updates
Implementation is via nested category keys in
source/StatisticsParser.Vsix/UnifiedSettings/registration.json — both the
categories block and the property monikers gain a .general / .display /
.updates segment.
Existing user-set values must survive the moniker rename. Preferred: a
migration block in registration.json mapping new monikers to old ones.
Fallback: a one-shot code-side copy in StatisticsParserPackage.InitializeAsync
gated by a persisted flag.
Full design notes: docs/OPTIONSGROUPING.md.
Alternatives considered
- Two groups (General / Updates) — minimal, but Display has enough
settings to warrant its own group.
- Four groups (split Display into Grid Appearance / Data Formatting) —
more granular but probably over-grouped for 7 total options.
- Leave flat — no work, but doesn''t scale as more options land.
Additional context
User-confirmed decisions captured in the design doc:
- Migration must preserve values (rename + migrate, not rename + reset)
- "Convert Completion Time to local time" belongs in Display, not Parsing
- Language belongs in General, not its own Parsing group
Description
The Tools > Options > Statistics Parser page currently lists all 7 settings as
a flat list. As options have accumulated, the page is hard to scan and there's
no obvious home for new settings. Group the options into three subcategories.
Use case / motivation
A flat list of unrelated toggles is harder to navigate than a grouped one, and
the page will only get worse as more options land. Subcategories make the
options page self-documenting (the group names communicate what each setting
affects) and give future options an obvious bucket.
Proposed solution
Three Unified Settings subcategories under
Statistics Parser:Implementation is via nested category keys in
source/StatisticsParser.Vsix/UnifiedSettings/registration.json— both thecategoriesblock and the property monikers gain a.general/.display/.updatessegment.Existing user-set values must survive the moniker rename. Preferred: a
migrationblock inregistration.jsonmapping new monikers to old ones.Fallback: a one-shot code-side copy in
StatisticsParserPackage.InitializeAsyncgated by a persisted flag.
Full design notes: docs/OPTIONSGROUPING.md.
Alternatives considered
settings to warrant its own group.
more granular but probably over-grouped for 7 total options.
Additional context
User-confirmed decisions captured in the design doc: