Condensing and simplifying Settings and Defaults

[marblewraith]

Greetings 👋

Preface: I am a VScode power user. I have around ~650 lines in my settings.json. I've been working longer hours as of late, and i've noticed my spelling suffers later in the day which brought me to Code Spell Checker.

However i was dumbfounded when i discovered it has 48 distinct settings. Some of them are completely transparent like "cSpell.maxNumberOfProblems", but others like "cSpell.checkLimit" are completely obfuscated (what even is K-limit?).

Am I crazy? Or do other people feel the API is a bit messy?

I did a search of issues and discussions, couldn't really find anything, so i figured why not start a thread to generate some conversation around possible improvements / issues that could be created?

I'll go first:

1. "cSpell.enabledLanguageIds" : Surely if you're going to have this many languages enabled by default, wouldn't it be better to have this as "cSpell.disabledLanguageIds" ?

2. The names of the settings in general, are not conducive to understanding where they should be declared. For example

• "cSpell.showStatus"
• "cSpell.maxDuplicateProblems"
• "cSpell.logLevel"
• "cSpell.diagnosticLevel"
• "cSpell.numSuggestions"

Unless i'm mistaken, these (and others) would nearly always be set within the general User settings.json file, whereas others such as "cSpell.ignoreWords" and "cSpell.words" could be set either globally or within workspace specific settings.

It'd help during setup to make this more clear, by using more granular namespacing, for example "cSpell.global.showStatus" or "cSpell.general.showStatus", somethin like that.

Anything else anyone can think of, don't hesitate to comment 😀

[Jason3S]

@marblewraith,

I agree with you that it is difficult to figure out what is going on. I wish VS Code had a way for extensions to work with the VS Code Preference UI beyond just listing all possible settings.

To be clear, I wold love some help with this, but it is not as simple as moving a few settings around.

The comments below are more to describe the situation or just ramble a bit:

The challenge here is that nearly ALL the cspell settings are exposed in the VS Code settings at the top level. This is historical and due to the fact that the VS Code only works on top level items. The VS Code Preferences UI has improved over the years. It went from a JSON editor to actually putting some UI on the simple items like booleans and string arrays. But it is very limited. The extension has some UI of its own. Click on:

It is not pretty, but it serves a valuable purpose.

1. Provide an overview of the spell checker.
2. Tries to show why a file is not checked and provide an easy to enable it or the file type.
3. List the dictionaries in use.
4. Allow changing the language locale.
5. Help troubleshoot when things are not working as expected.

None of these things are possible in the VS Code Preference UI.

Ideally, VS Code would allow extensions to define basic and advanced settings, hiding the complexity from the end user.

There are two basic scenarios in which the spell checker is used:

1. 100% of the configuration is in VS Code.
2. 10% (personal preferences) of the configuration is in VS Code, the rest is in a cspell.json or cspell.config.yaml file.

Scenario 1

This is the case where a project or code base does not have a CSpell integration. It is the general out of the box experience.

Scenario 2

This is the case where CSpell is part of the CI/CD process. Configuration is stored in the project as cspell.json or cspell.config.yaml. Most likely one or more custom dictionaries have been setup. Developers add to the dictionaries on a regular basis.