bug: Inconsistent use of underscores in VS Code settings

[hippietrail]

Describe the bug
Multi-word options for Harper itself don't have underscores between words, but options for individual links do.

To Reproduce
Steps to reproduce the behavior:

1. In VS Code hit ⌘-comma or control-comma to bring up the settings
2. In the "Search settings" box type "harper"
3. You will now only see Harper settings.
4. Notice some settings have spaces between words: Harper-ls › Code Actions: Force Stable, Harper-ls: Diagnostic Severity
5. But other settings have underscores between words: Harper-ls › Linters: Amazon_names, Harper-ls › Linters: An_a

Expected behavior
Consistency look and feel.

Screenshots

Platform
VS Code, Windsurf

[elijah-potter]

I thought I already replied here. Whack.

This is not in our control. VS Code produces the name of the setting from its key in the plugin's package.json. VS Code doesn't know how to handle snake_case. For backwards compatibility reasons, we cannot change those keys.

I remember reading an issue about this on the Visual Studio Code repo, but I can't seem to find it.

[hippietrail]

This is not in our control. VS Code produces the name of the setting from its key in the plugin's package.json. VS Code doesn't know how to handle snake_case. For backwards compatibility reasons, we cannot change those keys.

I remember reading an issue about this on the Visual Studio Code repo, but I can't seem to find it.

That sounds really unfortunate. I might try to chase it down on the VS Code side. Please come back and paste any links here if you find them.

[mcecode]

I did notice this before, but it didn't really bother me much since I set my VS Code settings directly in settings.json rather than in the GUI. However, I do agree that it would be nice if the setting keys would be consistent.

If we can't change it in harper-ls directly for backwards compatibility and VS Code can't handle snake case, then a workaround could be to set all the setting keys in package.json to camel case and transform what needs to be transformed into snake case before sending them to harper-ls. Though, I'm not really sure how to do that yet.

I wonder if it's a good idea to have a standard on whether new configs added to harper-ls should be snake case or camel case, so at least any new configs added would be uniform.

[hippietrail]

I did notice this before, but it didn't really bother me much since I set my VS Code settings directly in settings.json rather than in the GUI. However, I do agree that it would be nice if the setting keys would be consistent.

I think it will look unprofessional to some users.

If we can't change it in harper-ls directly for backwards compatibility and VS Code can't handle snake case, then a workaround could be to set all the setting keys in package.json to camel case and transform what needs to be transformed into snake case before sending them to harper-ls. Though, I'm not really sure how to do that yet.

I don't think it would be through packages/harper-ls but through packages/vscode-plugin
I think converting to snake case would be easy. I do wonder what the backwards compatibility is with, already installed Harper extensions on VS Code? If so couldn't we have a little updater that copies/moves the existing settings to the new names?

I wouldn't mind digging into the VS Code source to see if there's a way to address it on that end. I had a brief look yesterday but didn't find the right code yet.

[mcecode]

I don't think it would be through packages/harper-ls but through packages/vscode-plugin

Yup, this is what I meant. If consistency is what we want, we can make the setting names uniformly camel case in the VS Code extension's package.json and transform what needs to be into snake case before sending the config to harper-ls.

I do wonder what the backwards compatibility is with, already installed Harper extensions on VS Code?

It would be a breaking change since we'd be changing already existing setting names.

If so couldn't we have a little updater that copies/moves the existing settings to the new names?

You mean, provide a script that users can run against their setting.jsons and .code-workspace files?

[hippietrail]

I do wonder what the backwards compatibility is with, already installed Harper extensions on VS Code?

It would be a breaking change since we'd be changing already existing setting names.

So it's up to the main devs. To me it seems very early days like now is the best/easiest time to make breaking changes.

If so couldn't we have a little updater that copies/moves the existing settings to the new names?

You mean, provide a script that users can run against their setting.jsons and .code-workspace files?

Something like that. The VS Code extension may even be able to do it automatically, at least with asking the user permission first. I only have a tiny bit of experience with them so not sure what the restrictions are re editing files within and outside the open project.

[mcecode]

I do wonder what the backwards compatibility is with, already installed Harper extensions on VS Code?

It would be a breaking change since we'd be changing already existing setting names.

So it's up to the main devs. To me it seems very early days like now is the best/easiest time to make breaking changes.

Yup, we'd probably need a go signal from Elijah and maybe an announcement to users before introducing this change.

If so couldn't we have a little updater that copies/moves the existing settings to the new names?

You mean, provide a script that users can run against their setting.jsons and .code-workspace files?

Something like that. The VS Code extension may even be able to do it automatically, at least with asking the user permission first. I only have a tiny bit of experience with them so not sure what the restrictions are re editing files within and outside the open project.

Yeah, that might make the transition easier for users. AFAIK, extensions can edit files and such as long as it's trusted.

[elijah-potter]

Yup, we'd probably need a go signal from Elijah and maybe an announcement to users before introducing this change.

I'm incorporating it with my major refactoring in #726, alongside changes to how we declare new rules.