I like the idea.  It’s something that is sorely missing from the VS features.

From: Richard Birkby 
Sent: Monday, June 18, 2012 2:12 PM
To: [email protected] 
Subject: Re: [nhibernate-development] NHibernate coding standards

On Mon, Jun 18, 2012 at 1:01 PM, Stephen Bohlen <[email protected]> wrote:
  I think I'm a little unclear about the goal of this.  My initial thought was 
that if someone couldn't be expected to load a .vssettings file then getting 
them to install a plugin seems an even longer-shot :)


I never intended NHibernate to force contributors to install a plug-in! I see 
this system as making it easier for:

  1.. Existing contributors switching between projects with different 
tabs/spaces settings 
  2.. New contributors who see the paragraph about the EditorConfig plugin and 
realize installing a 76K plug-in will help them with settings 
  3.. Contributors who use other editors (eg Sublime2) to editor NH code
  But then I realized that the intent here might be more about providing a 
mechanism that would (more easily) support NH contributors using tabs when 
working on NH but spaces when working on other projects.  Is that the case?  I 
guess I'm trying to understand whether this .editorconfig approach is targeting 
 'regular contributors' or 'casual, one-time pull-requesters'.  Can you 
elaborate?


Currently, the only benefit to the one-time pull-requesters is maybe that they 
read the tiny paragraph about tabs/spaces and editorconfig. In the future *if* 
editorconfig gets more traction (and it looks like it is*), then a one-time 
pull requester will likely already have the plug-in installed.

  In either case, since having the .editorconfig file doesn't case *trouble* 
for anyone not running the plugin (right?), I don't have any issue with 
committing one to the repo.  But I'd also think that doing that *instead* of 
providing a .vssettings file probably isn't going to be sufficient for the 
'casual' contributor (e.g., telling them they have to install a vs plugin to 
contribute to NH is increased friction that I'd think we'd want to avoid).


I'm also very aware that adding extra stuff to a repo increases complexity in 
the same way as C# new features start at -100 points.
If no-one else thinks this is a good idea, that's fine. Everyone can keep the 
.editorconfig local to them.


Richard 
* https://twitter.com/paul_irish/statuses/212975948503588864

Reply via email to