Categories of lint in VS Code settings

[IFcoltransG]

What problem does this solve?
In VS Code settings, there are a lot of individual tickboxes for lints. To find consequential lints like Oxford comma or orthographic consistency that apply in many cases, you have to scroll through an ocean of hyperspecific lints like "bare in mind". Some important settings are at the very bottom after all linter settings, such as the Harper executable path.

Proposed Solution
Create settings subcategories within Harper, grouping lints into sections.

Examples
Incorrect idioms (e.g. "bare in mind") would be collected into one category. Proper nouns (e.g. Apple products, Azure products, Australian states) would be in their own category. Stylistic choices that are disabled by default (e.g. boring words, spelled numbers) could also be their own category. General settings not related to lints would be in their own category.

Component

• Core engine
• Plugin/Extension
• Other: _____

Additional Context
This kind of categorisation can be seen in the Rust Analyzer extension, for example.

[hippietrail]

I sometimes think about this problem. I think we could allow filtering by LintKind pretty easily, but those are not always easy to guess.

LintKind is a category but not necessarily always intuitive, and of course it doesn't allow multiple or overlapping categories.

Maybe we could have an optional array of "tags" that can be attached to every Linter specifically to make them more discoverable?

[mcecode]

Possibly related:

• Add General Ruleset Preset Toggles #1827
• Suggestion 3 in A few suggestions #1527 (grouping of linting rules)

---

I think we can group the general settings into their own category or put them before the linting settings, might make a PR for that if I get the time to get the ball rolling on this. However, as @hippietrail mentioned and AFAIK, we currently don't have a user-facing way of grouping/categorizing linting rules, but if we can establish that, then all we have to do is reflect it in the VS Code extension.

[hippietrail]

AFAIK, we currently don't have a user-facing way of grouping/categorizing linting rules, but if we can establish that, then all we have to do is reflect it in the VS Code extension.

We can probably do it externally too. At different levels too. For instance we could hard-code it into the VS Code extension and if it works out, migrate it into core, etc.

[mcecode]

We can probably do it externally too. At different levels too. For instance we could hard-code it into the VS Code extension and if it works out, migrate it into core, etc.

That could work, but it might incur additional maintenance work since the way we currently add new lint rule settings to the VS Code extension on release is automated by pulling any updates from harper-core via harper-cli through just update-vscode-linters. We'd probably end up needing to do some manual adjustments before every release to accommodate grouping through the VS Code extension.