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

Implement Naming Styles for editorconfig UI #58075

Conversation

jmarolf
Copy link
Contributor

@jmarolf jmarolf commented Dec 2, 2021

Related to #40163

This PR implements naming style support in 3 steps (and I would recommend reviewing this PR step-by-step)

  • d77a8f8 Implement a parser for editorconfig files
  • 5e5cbc8 build support on top of the parser for discovering and updating naming style options
  • a773abe provide a UI on top of these new services

image

This adds all the capabilities necessary to discover and update naming styles in an editorconfig. depends on the parser functionality added in previous commit
This adds a new tab for the naming style options that were exposed via services in a previous commit
@jmarolf jmarolf requested review from ryzngard and a team December 2, 2021 16:31
@ghost ghost added the Needs UX Triage label Dec 2, 2021
else
{
var span = new TextSpan(sourceText.Length, 0);
newNamingStyleSection.Append("\r\n");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use Environment.NewLine here?

jmarolf and others added 2 commits December 2, 2021 10:01
…ngStyles/EditorConfig/EditorConfigNamingStyleParser_NamingStyle.cs

Co-authored-by: Joey Robichaud <jorobich@microsoft.com>
…orConfig/readme.md

Co-authored-by: Joey Robichaud <jorobich@microsoft.com>
Copy link
Member

@Youssef1313 Youssef1313 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a parser in the compiler. I'm not a big fan of duplicating part of that logic. Is there a way to reuse the existing compiler support for EditorConfig?

@ryzngard
Copy link
Contributor

ryzngard commented Dec 2, 2021

Implement a parser for editorconfig files

This scares me 👀

@Youssef1313
Copy link
Member

One thing I've always wondered about the EditorConfig UI, how will it be able to handle scenarios where different directories have different settings. This is far from being something to do in this PR, but sharing my thought anyway to consider.

@jmarolf
Copy link
Contributor Author

jmarolf commented Dec 2, 2021

There is already a parser in the compiler. I'm not a big fan of duplicating part of that logic. Is there a way to reuse the existing compiler support for EditorConfig?

I mention this here: https://github.com/jmarolf/roslyn/blob/features/editorconfig-naming-style-support/src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/EditorConfig/readme.md but then I asked you to review specific commits so this is what I get ¯_(ツ)_/¯

The compilers implementation has some rather big perf requirements and I don't want them to take on the additional complexity . Also the way I've done section parsing includes several cases that the compiler does not need to worry about. Would like to unify these someday but I think the requirements diverge enough that I went with a separate implementation that meets our needs

// Matches EditorConfig section header such as "[*.{js,py}]", see https://editorconfig.org for details
private static readonly Regex s_sectionMatcher = new(@"^\s*\[(([^#;]|\\#|\\;)+)\]\s*([#;].*)?$", RegexOptions.Compiled);
// Matches EditorConfig property such as "indent_style = space", see https://editorconfig.org for details
private static readonly Regex s_propertyMatcher = new(@"^\s*([\w\.\-_]+)\s*[=:]\s*(.*?)\s*([#;].*)?$", RegexOptions.Compiled);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmarolf One of the reasons I'm worried about two parser implementations is something like #51625, which proposes a change to the s_propertyMatcher regex. It's likely we can miss any changes of those kind here. Probably some code comments in each place referring to the other would do it for now until this is unified?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in a world where there was a formal spec that we could write against this would be less of a concern but things being as they are I agree we don't want to do this for no reason. I am still of the opinion that this is justified considering the compilers' requirements.

I will add test cases for the comment parsing to both implementations so that if someone ever updates one version and not the other CI will fail.

jmarolf and others added 2 commits December 2, 2021 11:00
…les/EditorConfigNamingStylesExtensions.cs

Co-authored-by: Youssef Victor <youssefvictor00@gmail.com>
…les/EditorConfigNamingStylesExtensions.cs

Co-authored-by: Youssef Victor <youssefvictor00@gmail.com>
@jmarolf
Copy link
Contributor Author

jmarolf commented Dec 2, 2021

One thing I've always wondered about the EditorConfig UI, how will it be able to handle scenarios where different directories have different settings. This is far from being something to do in this PR, but sharing my thought anyway to consider.

I would love to hear ideas. My plan is to is to augment the location column (which you added :)) so that you can navigate to different editorconfig or globalconfig files if the one you are in is not where the options definition currently resided.

My expectation is that the UI is a view over a single file showing the rules that are defined there as well as the "implicit" rules that it is pulling from elsewhere. Editing therefore always applies to the file you are viewing but we can make navigating across files better. We can also add additional columns so that sorting and filtering is easier.

Another case that I would like to handle is different rules across different sections in the same file. I currently punt on things like this:

[*.cs]
# C# specific settings
[*.vb]
# Visual Basic specific settings
[*.{cs,vb}]
# Settings for both

If there are duplicated rules. My hope is that I could show duplicated rules as duplicates in the list with a column showing the section they come from to disambiguate

@jmarolf jmarolf force-pushed the features/editorconfig-naming-style-support branch from 4121f55 to 74e9ca0 Compare December 3, 2021 22:42
Copy link
Contributor

@ryzngard ryzngard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review 1/3 done

Copy link
Contributor

@ryzngard ryzngard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2/3 done

internal SymbolSpecification? Type { get; set; }

public string StyleName => Style.Name;
public string[] AllStyles => _allStyles.Select(style => style.Name).ToArray();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be ImmutableArray<string>


internal void ChangeStyle(int selectedIndex)
{
if (selectedIndex > -1 && selectedIndex < _allStyles.Length && Location is not null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this throw index out of bounds?

public static void AppendNamingStylePreferencesToEditorConfig(IEnumerable<NamingRule> namingRules, StringBuilder editorconfig, string? language = null)
{
var symbolSpecifications = namingRules.Select(x => x.SymbolSpecification).ToImmutableArray();
var namingStyles = namingRules.Select(x => x.NamingStyle).ToImmutableArray();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably not a huge deal, but doing ToImmutableArray() here is slightly more expensive than just leaving as an IEnumerable since you're going to just enumerate again and not use the ImmutableArray. That ore combine with the Select below for one chained LINQ

Copy link
Contributor

@ryzngard ryzngard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good. Nothing blocking, minor feedback here and there. The Readme.md files were really helpful and I'm glad they're being checked in. One slight improvement would be to call them out in the PR description (I know it's tough/impossible to link) just so we know to look for them :) Hopefully we can start adopting this for future PRs as a team

@@ -0,0 +1,22 @@
# Editorconfig settings providers and updaters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 this is a great idea. Love the contextual markdown files.

@jmarolf jmarolf merged commit 032a9be into dotnet:release/dev17.1 Dec 7, 2021
@jmarolf jmarolf deleted the features/editorconfig-naming-style-support branch December 7, 2021 18:51
@ryzngard ryzngard added UX Review Not Required UX Review Not Required and removed Needs UX Triage labels Apr 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants