Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EditorConfig file and language sub-entry #4421

Merged
merged 2 commits into from
Mar 2, 2019
Merged

Add EditorConfig file and language sub-entry #4421

merged 2 commits into from
Mar 2, 2019

Conversation

Alhadis
Copy link
Collaborator

@Alhadis Alhadis commented Feb 14, 2019

This is a two-part PR related to the EditorConfig format, which I'll describe in ascending order of importance:

1. Language sub-entry

Recently, I took over maintainer duties for Atom's editorconfig package, which included a grammar for .editorconfig files. Naturally, I couldn't help rewriting it to fix various errors in Atom's highlighting — I figure if there's a dedicated grammar for EditorConfig files, we might as well use it on GitHub too.

I understand this might be pushing it, since the INI grammar provides decent-looking highlighting:

Visible differences to highlighting include file-globbing operators (like ** and *) and tokenisation of bracket-pairs embedded in [{section,titles}], which are EditorConfig-specific facets.

2. Linguist's own .editorconfig file

I've added an EditorConfig for Linguist, so contributors with editors configured differently to GitHub's preferences (like myself 😝) can edit files without configuring their program to use a different tabstop-width or indentation style.

I should stress the addition of this file will not affect automation or tests in any way. It's strictly for the benefit of contributors, as it only changes what settings their editor of choice uses when hacking on Linguist.

Virtually every modern text-editor supports .editorconfig files either out-of-the-box or with a community-maintained plugin. Even GitHub acknowledges these files when determining what tab-width to use when displaying source code (albeit with various shortcomings, each of which I've reported at least twice now...)

Checklist:

  • I am adding a new language.
    • The extension of the new language is used in hundreds of repositories on github.com.
    • I have included a real-world usage sample for all extensions added in this PR:
      • It's simply INI's sample for .editorconfig
    • I have included a syntax highlighting grammar:

@Alhadis Alhadis requested review from pchaigno and lildude and removed request for pchaigno and lildude February 14, 2019 07:06
@Alhadis
Copy link
Collaborator Author

Alhadis commented Feb 14, 2019

Ugh, sorry about the switch-a-roo of review-requests.... Internet (and GitHub) are lagging... 😢

@pchaigno
Copy link
Contributor

I didn't know EditorConfig. Looks nice!

I understand this might be pushing it, since the INI grammar provides decent-looking highlighting:

It's probably for the best, the INI grammar is not receiving a lot of attention.

@Alhadis
Copy link
Collaborator Author

Alhadis commented Feb 14, 2019

While I'm reminded, I should confess I had a dream a few weeks ago where I got in trouble with GitHub staff for accidentally committing a Ruby file to Linguist with tabs in it. Seriously.

Starting to think I need help...

@Arcensoth Arcensoth mentioned this pull request Feb 17, 2019
4 tasks
@Alhadis Alhadis merged commit 981882c into master Mar 2, 2019
@Alhadis Alhadis deleted the editorconfig branch March 2, 2019 05:40
@github-linguist github-linguist locked as resolved and limited conversation to collaborators Jun 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants