Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSCode 1.9.0 - Diagnostics always showing even when ext is not the formatter #1403

Open
scabana opened this issue Dec 9, 2024 · 4 comments

Comments

@scabana
Copy link
Contributor

scabana commented Dec 9, 2024

Environments

  • IDE Version: vscode 1.95
  • Extension Version: 1.9.0
  • CSharpier Version: 0.30.3
    will NOT be the same as the extension version
  • Operating System: windows 11
  • .csharpierrc Settings: none
  • .editorconfig Settings: none

Log Output

Steps to reproduce

  1. Install csharpier dotnet tool globally
  2. Install vscode extension
  3. Do not make csharpier the default formatter
  4. Open a project
  5. Open a cs file

Expected behavior

When CSharpier is not the selected formatter, no diagnostics should show up.

When adopting CSharpier, not all repositories will have CSharpier setup.

Actual behavior

CSharpier diagnostics shows up (seems related to this commit

@belav
Copy link
Owner

belav commented Dec 9, 2024

I've added an option to disable this for now. I think It makes sense to disable these diagnostics when csharpier is not the formatter.

@badsyntax do you happen to know how to find the current formatter? I was thinking it would be quick to make this change but wasn't able to track down how to get that information in an extension.

@belav belav added this to the Planned - Extensions milestone Dec 9, 2024
@scabana
Copy link
Contributor Author

scabana commented Dec 10, 2024

This is awesome! I think keeping the option in the long run might even be a good thing. For the little I saw the result, is really was in my way.

@badsyntax
Copy link
Contributor

@belav I'll take a look later this week

@alex-de-haas
Copy link

Nice solution. I agree with @scabana that the option should be left.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants