On 05/06/2016 11:05 AM, [email protected] 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 -- You received this message because you are subscribed to the Google Groups "EditorConfig" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/editorconfig. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
