Both Ascribe and EditorConfig have clear advantages and disadvantages. I have created this page to provide an overview and basic comparison between the two tools, to enable you to make an informed decision about which one to use.
EditorConfig is a standard which defines a file (
.editorconfig), and a format for that file. The standard also defines several options which that file can contain, each of these options can change the behaviour of the developer's editor when editing specific files.
In order for the behaviour of an editor to be altered, an extension needs to be installed to that specific editor (some editors support the EditorConfig standard out-of-the-box).
The EditorConfig project develops multiple parsers for their custom file format, written in a range of languages; intended to be used within the editor extensions they create.
EditorConfig does not depend on any version control tools.
The Ascribe standard reuses the
.gitattributes file commonly found in many projects. It defines how to use specific attributes in the
.gitattributes to alter the behaviour of editors.
Ascribe makes use of the existing attributes commonly used by Git (e.g.
binary), and adds some editor specific ones on top. These attributes are used by Ascribe extensions which can be installed to the editor.
Since Ascribe uses the
.gitattributes file, and reuses some of the existing attributes, several important options are enforced at the VCS level by Git. This reduces problems for developers who don't use a supported editor.
Ascribe depends on the Git version control system.
.editorconfigfiles are easier to understand than
.gitattributesfile to get information (for example GitHub's file type detection can be overridden using the
linguist-languageattribute), this makes
.gitattributesparsers much more useful than their
.gitattributesfile format is difficult to understand.