Dialect indicator for VS Code extension

[hippietrail]

Issues

#982

Description

Adds an indicator in the status bar for the English dialect set.

It reflects the Workspace setting, which seems to be the default. I don't know VS Code or its extension system deeply enough to know if this is the best solution.

On my setup I was able to confuse myself by changing the dialect in User.

Changing the Workspace setting instantly changes the flag, but does not reload the window. Some squiggles seem to be updated instantly, but not all of them.

It is possible to make the indicator clicking to change the setting but I haven't implemented this. It would be best to fully grok the Workspace vs User ramifications before attempting this.

It is possibly to add a Harper logo but not as a PNG or SVG. You need to do some font trickery: https://stackoverflow.com/a/76399730/527702

I tried to make the indicator appear as close to the document format indicator as possible. It doesn't seem to be possible to get them right next to each other.

Demo

View from the settings:

View of position near file format indicator:

How Has This Been Tested?

Manually. I don't know if it would be possibly to add test code for this. Let me know.

Checklist

• I have performed a self-review of my own code
• I have added tests to cover my changes

[mcecode]

It reflects the Workspace setting, which seems to be the default. I don't know VS Code or its extension system deeply enough to know if this is the best solution.

It's probably the right move, AFAIK, using workspace.getConfiguration like you did returns the setting for the current open workspace/folder. If that's not set, it returns the user level setting. If that's not set, it returns the default setting.

Changing the Workspace setting instantly changes the flag, but does not reload the window. Some squiggles seem to be updated instantly, but not all of them.

The window doesn't need to reload on config change. Updating the diagnostics on config change is already handled here:

harper/packages/vscode-plugin/src/extension.ts

Line 89 in 77376c7

if (configs.find((c) => event.affectsConfiguration(c))) {

I tried to make the indicator appear as close to the document format indicator as possible. It doesn't seem to be possible to get them right next to each other.

You can probably achieve this by setting priority to 1 or -1 like Prettier or Biome do.

I have some nits, but for now, LGTM.

[hippietrail]

It reflects the Workspace setting, which seems to be the default. I don't know VS Code or its extension system deeply enough to know if this is the best solution.

It's probably the right move, AFAIK, using workspace.getConfiguration like you did returns the setting for the current open workspace/folder. If that's not set, it returns the user level setting. If that's not set, it returns the default setting.

I know I got confused when coding it and then when testing it, but I'm not comfortable with the various levels of settings in VS Code. If it feels right to VS Code pros that's great!

Changing the Workspace setting instantly changes the flag, but does not reload the window. Some squiggles seem to be updated instantly, but not all of them.

The window doesn't need to reload on config change. Updating the diagnostics on config change is already handled here:

harper/packages/vscode-plugin/src/extension.ts

Line 89 in 77376c7

if (configs.find((c) => event.affectsConfiguration(c))) {

Great! I got the feeling that some squigglies updated if they were hidden by another window and that others were not updated. But that may be a false impression. .affectsConfiguration() looks like the API I was hunting for and failed to find to force a window refresh/redraw/invalidation. Much of this documentation is written in too abstract a style IMO. Googling and asking LLMs didn't get me there either using more concrete terminology.

I tried to make the indicator appear as close to the document format indicator as possible. It doesn't seem to be possible to get them right next to each other.

You can probably achieve this by setting priority to 1 or -1 like Prettier or Biome do.

I did a manual bsearch over the priorities. -1 behaves the same as any value <= 100, between Copilot and Notifications. If you feel that's a better spot I'm happy to change it. Here's what it looks like for comparison:

I have some nits, but for now, LGTM.

Please bring them on. I'm a lot less comfortable in this code than in the core Rust code.

[mcecode]

I know I got confused when coding it and then when testing it, but I'm not comfortable with the various levels of settings in VS Code.

I guess you can visualize it like CSS, the settings cascade. From less to more specific, it goes, default settings, user settings, then workspace settings. If the more specific setting is not set, then it falls back to less specific settings until you end up in the default setting. I don't know if that'll help, but that's how I imagine it.

Much of this documentation is written in too abstract a style IMO. Googling and asking LLMs didn't get me there either using more concrete terminology.

I feel you on this. Docs and blogs outside of the official documentation are also sparse, that's probably why LLMs aren't very good at this, there's just not a lot of non-code data. If I need to do something specific or edge case, like in the case of middlewares, I usually have to hunt what API I need in .d.ts files and GitHub issues.

If you feel that's a better spot I'm happy to change it.

I don't really have a preference, I just thought those values might put it closer to where you want it to be.

Please bring them on. I'm a lot less comfortable in this code than in the core Rust code.

They're really just nits on the structure, nothing that should block the PR. Functionality-wise, this is good.