Creating native Visual Studio EditorConfig support

[mwth...@microsoft.com]

Hi EditorConfig developers and contributors

 

I’m a Program Manager on the Visual Studio Editor team.

In response to strong customer support for the feature (see https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/6146845-support-editorconfig for example), we’re looking at  providing all-new, native support for EditorConfig in the core Visual Studio product in a future release.   We would aim to make the new EditorConfig support in Visual Studio propagate settings to VS in a manner that is more flexible and usable than what is currently possible for a VS extension.

 

In addition, we’re planning work to provide smart support for other coding convention settings in our language services, and we’d like to leverage EditorConfig to express a (potentially large) number of such settings, via domain-specific entries in an EditorConfig file. We would want to do so in a manner that does not cause any trouble or collisions for other EditorConfig implementations (see my colleague Oleg’s a conversion on editorconfig mail list), so for those settings, we’d want to follow what seems to be the normal pattern of editorname_settingname.

 

I wanted to reach out to the EditorConfig community at this stage, and ask:

 

1.       Is adding (potentially large) numbers of custom settings to the format for our purposes reasonable?

2.       Are there particular ways you’d prefer us to work with the format as we do this?

 

Thanks in advance for your commentary and help,

 

Regards

Mark Wilson-Thomas

Program Manager, Visual Studio Editor Team

[Hong Xu]

On 05/06/2016 11:05 AM, mwth...@microsoft.com wrote:
> I’m a Program Manager on the Visual Studio Editor team.
>
>
> In response to strong customer support for the feature (see

> _https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/6146845-support-editorconfig_for

> example), we’re looking at providing all-new, native support for
> EditorConfig in the core Visual Studio product in a future release. We
> would aim to make the new EditorConfig support in Visual Studio
> propagate settings to VS in a manner that is more flexible and usable
> than what is currently possible for a VS extension.
>
>
>
> In addition, we’re planning work to provide smart support for other
> coding convention settings in our language services, and we’d like to
> leverage EditorConfig to express a (potentially large) number of such
> settings, via domain-specific entries in an EditorConfig file. We would
> want to do so in a manner that does not cause any trouble or collisions

> for other EditorConfig implementations (see my colleague Oleg’s _a
> conversion on editorconfig mail list_
> <https://groups.google.com/forum/#!topic/editorconfig/7w9BmR8LBmU>), so

> for those settings, we’d want to follow what seems to be the normal
> pattern of editorname_settingname.
>
>
>
> I wanted to reach out to the EditorConfig community at this stage, and ask:
>
>
>
> 1. Is adding (potentially large) numbers of custom settings to the
> format for our purposes reasonable?
>
> 2. Are there particular ways you’d prefer us to work with the
> format as we do this?
>

Hi Mark,

Thanks for contacting us. We are glad to offer help.

Yes, it is reasonable to add a potential large numbers of custom
settings. The only concern to me are the names for property names and
values, which we want to stay unified across all available platforms
(IDEs/editors). I would categorize the situation into two cases:

* You want to map the names of the settings in Visual Studio
configuration files (e.g. *.sln) to some property names in editorconfig
files. In this case, you are welcome to use the the prefix of
"visualstudio_". If we find some of the properties useful, we can
support them by removing the prefix, or potentially rename them to fit
into the EditorConfig context -- and Visual Studio can then support the
"removed prefix" version of them.

* You want to create some new settings that are mostly useful for cross
editor features and/or do not necessarily map exact settings in Visual
Studio. This is about what EditorConfig originally wants to do -- the
core purpose of editorconfig is about unifying some elements (coding
style or other settings) of a project for different editors/IDEs
preferred by team members. In this case, even it's a large number of
settings (maybe a few hundred?), although I trust your team on giving
adequate names, my suggestion would still be posting the names out and
having a discussion to make sure that the EditorConfig community is
happy with them.

You probably also want to check out the wiki page
<https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties>
for the existing names we have.

Hong

[Mark Wilson-Thomas]

Hi Hong Xu

Thanks for your advice and guidance. We’ll be happy to publish proposed lists of domain specific settings for review once we have them ready. We’ll work on how exactly we’ll do that and let you guys know once they are ready for review.

 

Regards

 

Mark