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 On Friday, May 6, 2016 at 8:37:11 PM UTC-7, Hong Xu wrote: > On 05/06/2016 11:05 AM, [email protected] <javascript:> 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.
