[WIP] Note native Github support and link to Ruby core library

[treyhunner]

Github added support for EditorConfig last week. This required a Ruby core library which was created by @josh and @brianmario.

This change seems to include full support for indentation when viewing diffs and file blobs and nearly full support for indentation when editing files (tab_width is not supported independently of indent_size, similar to the way Gedit and other plugins handle it). No other properties appear to be supported by the editor currently.

Indentation when viewing files is by far the most important support needed on Github given that nearly all Github users view files in the browser (through pull requests or otherwise).

I believe the current Github browser extension by @RReverser also only includes support for indentation. If this is the case, this browser extension may no longer be necessary.

If the Github browser extension is no longer necessary, how should we note the Github support on the EditorConfig homepage?

I see a couple possibilities:

1. Link to a landing page of sorts that notes that Github now supports EditorConfig and explaining the extent of the support
2. Use an in-page dialog box to note the support (don't link to another page)
3. Continue to link to the Github browser extension README file and update the README file to note the native support

I am leaning toward option 1. I like the idea of a page dedicated to explaining Github's support of EditorConfig similar to the way it is explained for some of the other editors that natively support it. This page could be controlled and hosted on github.com (maybe help. or blog.), editorconfig.org, or elsewhere.

[RReverser]

I added deprecation message to extension README for now in RReverser/github-editorconfig@1914fa7.

Let me know when you have proper link I could use there and I'll replace.

[RReverser]

Wait, does Github support trim_trailing_whitespace and insert_final_newline as well? If no, I should probably update extension and remove indentation stuff but not deprecate it completely.

[johan]

I'd love to show metadata per editor noting which properties are supported, as inattentive peers running webstorm and similar manage to keep overriding the settings in various .editorconfig files despite the (presumably partial) support it's supposed to have.

For that level of documentation, we'd probably have to start running something like jekyll and building per-editor sections generated from yaml/cson/json or similar files ticking off no/partial/complete support per feature, though. Thoughts on if that would feel worthwhile to anyone else?

[xuhdev]

I'm leaning toward option 1. Github.com may probably have a page for EditorConfig support. Also, we should really have a blog and an announcement mailing list... There are too many news which we have never announced formally!

[treyhunner]

@johan I'm not sure if we'd even need Jekyll for the feature you suggest. It seems like a JSON blob in a JavaScript file should be good enough to make check boxes for demonstrating option support.

[treyhunner]

I think linking to the readme for @RReverser's plugin is good enough for now. The GitHub icon is now moved up to the "no plugin necessary" section and the Ruby library is linked to.

[josh]

Woah, thanks!!!!

Wait, does Github support trim_trailing_whitespace and insert_final_newline as well? If no, I should probably update extension and remove indentation stuff but not deprecate it completely.

Ha, well, I can probably implement those by hacking it into our Ace extensions if thats all it takes to obsolete https://github.com/RReverser/github-editorconfig 😀

[RReverser]

@josh And no more GitHub stars? 😭

[RReverser]

If talking seriously, yes, that would be useful - and I've anyway already put "deprecated" message on the repo.

[johan]

@johan I'm not sure if we'd even need Jekyll for the feature you suggest. It seems like a JSON blob in a JavaScript file should be good enough to make check boxes for demonstrating option support.

D'oh; true! Not sure why I was thinking from a markdown-only-centric point of view. Given front-end js, that's the obvious and trivial solution.

[kevinSuttle]

Forgive my tardiness, but what exactly does "GitHub supports EditorConfig natively now" mean? Supports it where? How?

[jwheare]

Github doesn't support trim_trailing_whitespace when editing files, so the browser extension is still needed.

[ianstormtaylor]

@josh any word on the above issue of GitHub not supporting trim_trailing_whitespace? Makes it frustrating when making tweaks in the UI that then break the linting tests.