EditorConfigLanguage
EditorConfigLanguage copied to clipboard
madskristensen
Missing Settings
Installed product versions
- Visual Studio: 2017 Enterprise
- This extension: 1.16.198
Description
Missing csharp settings in https://github.com/dotnet/roslyn/pull/15020 and https://github.com/dotnet/roslyn/pull/15065. You seem to have added support for settings in https://github.com/dotnet/roslyn/pull/15029.
Steps to recreate
- Show intellisense
- No tooltip for the settings in the above link
You can show the ones from dotnet/roslyn#15020 under Tools -> Options
The naming style rules from dotnet/roslyn#15065 are in the CI build that hasn't been released yet. You can install it from http://vsixgallery.com/extension/1209461d-57f8-46a4-814a-dbe5fecef941/ I'd love to get your feedback on it before I release it officially.
@jasonmalinowski are the rules from https://github.com/dotnet/roslyn/pull/15020 still undocumented?
Still not sure if we have it formally written up. I guess we need to get on that. @jmarolf did we do this somewhere?
@jasonmalinowski These were intentionally undocumented as per @pilchie @kuhlenh
@madskristensen just curious why a fix to Roslyn's editorconfig support that was merged into master on Dec. 21st didn't make it into the VS2017 release - does it take that long for that kind of a fix to make it through? Not judging - just wondering
@HintonBR They are not sure if some of the settings will remain. All of them come from VS options. Apparently, one of the settings was only changed by 6 people in VS history (of those who report VS usage statistics to Microsoft). Once a decision is made, the remaining settings will be documented.
@jasonmalinowski I have the RTW version of VS2017 - so you are saying those settings will be respected? I thought I tried it and it didn't work, but perhaps I made a mistake.
Sorry the settings around naming (like how to name private variables etc...). I should have clarified that as I didn't really in the posts above. The naming convention support was checked into the Roslyn repo on Dec. 21st, but I couldn't get that support to work in VS2017 RTW. that is what I was asking about. For the EditorConfig language extension I don't know if support for the the naming style settings has been added, but if VS2017 doesn't support them yet then it wouldn't make sense for the extension to support them.
@HintonBR please post the editorconfig settings you used. Naming styles are supported in VS2017 RTW.
Is there a comprehensive reference all in one place? This is all I can find and it's a small percentage: https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference
Additionally, none of the settings I really cared about were in there. 😄
It looks like I could generate the list of supported settings by parsing these files:
https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/Core/Portable/CodeStyle/CodeStyleOptions.cs https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/Core/Portable/Editing/GenerationOptions.cs https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/Core/Portable/Formatting/FormattingOptions.cs https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/Core/Portable/Simplification/SimplificationOptions.cs https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/CSharp/Portable/CodeStyle/CSharpCodeStyleOptions.cs https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/CSharp/Portable/Formatting/CSharpFormattingOptions.cs
But proper documentation would just be awesome.
I think I found a bug. Looks like it should be "csharp_space_around_binary_operators", not "csharp_space_around_binary_operators " with the extra space.
https://github.com/dotnet/roslyn/blob/version-2.2.0/src/Workspaces/CSharp/Portable/Formatting/CSharpFormattingOptions.cs#L126
It was in master too so I filed https://github.com/dotnet/roslyn/issues/20355.
So in the current release (2.2.0), this is the list of supported editorconfig settings:
end_of_line
indent_size
indent_style
tab_width
dotnet_sort_system_directives_first
dotnet_style_coalesce_expression
dotnet_style_collection_initializer
dotnet_style_explicit_tuple_names
dotnet_style_null_propagation
dotnet_style_object_initializer
dotnet_style_predefined_type_for_locals_parameters_members
dotnet_style_predefined_type_for_member_access
dotnet_style_qualification_for_event
dotnet_style_qualification_for_field
dotnet_style_qualification_for_method
dotnet_style_qualification_for_property
csharp_indent_block_contents
csharp_indent_braces
csharp_indent_case_contents
csharp_indent_labels
csharp_indent_switch_labels
csharp_new_line_before_catch
csharp_new_line_before_else
csharp_new_line_before_finally
csharp_new_line_before_members_in_anonymous_types
csharp_new_line_before_members_in_object_initializers
csharp_new_line_before_open_brace
csharp_new_line_between_query_expression_clauses
csharp_prefer_braces
csharp_preserve_single_line_blocks
csharp_preserve_single_line_statements
csharp_space_after_cast
csharp_space_after_colon_in_inheritance_clause
csharp_space_after_comma
csharp_space_after_dot
csharp_space_after_keywords_in_control_flow_statements
csharp_space_after_semicolon_in_for_statement
# https://github.com/dotnet/roslyn/issues/20355
csharp_space_around_binary_operators
csharp_space_around_declaration_statements
csharp_space_before_colon_in_inheritance_clause
csharp_space_before_comma
csharp_space_before_dot
csharp_space_before_open_square_brackets
csharp_space_before_semicolon_in_for_statement
csharp_space_between_empty_square_brackets
csharp_space_between_method_call_empty_parameter_list_parentheses
csharp_space_between_method_call_name_and_opening_parenthesis
csharp_space_between_method_call_parameter_list_parentheses
csharp_space_between_method_declaration_empty_parameter_list_parentheses
csharp_space_between_method_declaration_name_and_open_parenthesis
csharp_space_between_method_declaration_parameter_list_parentheses
csharp_space_between_parentheses
csharp_space_between_square_brackets
csharp_style_conditional_delegate_call
csharp_style_expression_bodied_accessors
csharp_style_expression_bodied_constructors
csharp_style_expression_bodied_indexers
csharp_style_expression_bodied_methods
csharp_style_expression_bodied_operators
csharp_style_expression_bodied_properties
csharp_style_inlined_variable_declaration
csharp_style_pattern_matching_over_as_with_null_check
csharp_style_pattern_matching_over_is_with_cast_check
csharp_style_throw_expression
csharp_style_var_elsewhere
csharp_style_var_for_built_in_types
csharp_style_var_for_locals
csharp_style_var_when_type_is_apparent
Hey @jnm2 -- we haven't documented all of the features yet because we're still determining which to support. For example, "space after/before dot" is a style that almost no one follows...
The full documented list should be out when Visual Studio 2017 version 15.3 ships!
That's great news!
Here's some of the ones I needed to work in DevExpress's codebase without going insane:
csharp_new_line_before_open_brace = none
csharp_new_line_before_catch = false
csharp_new_line_before_else = false
csharp_new_line_before_finally = false
csharp_space_after_keywords_in_control_flow_statements = false
@kuhlenh I'm sorry, but this is really quite frustrating. February the bug was reported and March you said the bug was fixed, and this is still keeping us from being able to use charset in July. Would you please update us with an ETA?
https://developercommunity.visualstudio.com/content/problem/22922/editorconfig-support-interprets-charset-utf-8-as-u.html
Hi @jnm2 -- the bug you are referring to here ^ is fixed and will appear in a future release (I believe Visual Studio 2017 version 15.3). The documentation for the .NET code style rules will be completed by version 15.3 as well. Hope that helps!
And for what it's worth, you can install the Visual Studio 2017 Preview today to try it out from https://www.visualstudio.com/vs/preview) to try it out. It installs side-by-side with your existing Visual Studio 2017 installation.
@kuhlenh It really helps to give people an ETA. We can see that the bug is fixed, but it's just weird to totally ignore people for four months. The silence is the only really frustrating part.
I wish the fix could be backported. What I'm afraid of, if we add this to OSS projects, is that people running 15.0 - 15.2 will accidentally convert a bunch of files. There's no way for us to make the .editorconfig line be conditionally ignored by specific versions of VS, is there? Otherwise we probably won't be able to use this until we're sure no one is using VS 15.0 - 15.2.
Thanks @Pilchie, I guess that's one way to reverse engineer the milestones for issues I'm tracking. =) I'll try it when I get a chance.
@jnm2 - we have a policy to not talk about release dates for upcoming releases, because they can always change (we are dealing with software here 😉 ). With that said, Visual Studio 2017 has a general policy that significant feature updates to core components (like the editor, Roslyn, etc), don't tend to happen in every update, because we don't want to risk destabilizing things that depend on them. That's why this sort of thing didn't appear in the 15.1 or 15.2 updates.
I know it's confusing though, and I wish we had a better mechanism for telegraphing target releases and ETAs. One of the tough intersections of commercial box software and OSS :-/
I know it's confusing though, and I wish we had a better mechanism for telegraphing target releases and ETAs. One of the tough intersections of commercial box software and OSS
Please don't stop thinking about it. I spoke up because this is only the most recent in a series of experiences, in one of which I was ignored for seven months and then nine months. If you don't know, saying "I don't know" is light years ahead of pretending I didn't ask a question.
One suggestion I have already is that if this fix is in 15.3 Preview 3, it's probably safe to tell the people following the developercommunity.visualstudio.com issue who haven't heard from you since March that the fix is in 15.3 Preview 3.
we have a policy to not talk about release dates for upcoming releases, because they can always change (we are dealing with software here 😉 ).
There might be a misunderstanding here. I did say ETA, but I don't care what a release's date is. What I should have said to be super accurate was, we want to know a tentative version number to keep an eye out for. That way we know it's worth our time to download the specific preview containing the fix and also so that we can notice when you release that version number so we know when to expect other people to be using it.
With that said, Visual Studio 2017 has a general policy that significant feature updates to core components (like the editor, Roslyn, etc), don't tend to happen in every update, because we don't want to risk destabilizing things that depend on them. That's why this sort of thing didn't appear in the 15.1 or 15.2 updates.
That makes sense, but we're talking about a particular bug fix that I doubt you would call a significant feature update. Coupled with a concern that fixing it in 15.3 without fixing it in earlier versions is going to mean, functionally, that OSS projects won't be able to use it until most people are off 15.0 - 15.2. Effectively perhaps the 15.4 or 15.5 timeframe.
I did say ETA, but I don't care what a release's date is.
Got it - I will pass along the feedback (again), that the "Fixed - Pending Release" tag in Developer community should include target information.
bug fix that I doubt you would call a significant feature update
This is of course subjective. In fact, for core components like the editor, the 15.1 and 15.2 releases only contain bug fixes for things like crashes affecting hundreds to thousands of customers. We're slowly getting better at delivering fixes quickly, but we want to make sure that those fixes are always improving the quality of VS, and so we're fairly risk averse to avoid introducing regressions.
I'm sorry, I really don't enjoy the role of being the one saying this! I love what you are doing. You are making devs happy.
No need for an apology! It's great feedback, and a good discussion to be having.
Is there a setting for including/excluding the default visibility accessors? I.e., don't use private for fields or methods of a class, etc?
