Make EditorConfig explicit #279

florianb opened this Issue Nov 8, 2016 · 4 comments


None yet

3 participants

florianb commented Nov 8, 2016 edited

Some parts of the documentations are ambiguous - for example:


Indentation Size (in single-spaced characters)

The values are case insensitive. They will be lowercased by the core library.

Possible Values

an integer



Width of a single tabstop character

Possible Values

a positive integer (defaults indent_size when indent_size is a number)

The indent_size is case insensitive, the tab_width isn't.
The tab_width allows only positive integers, the indent_size doesn't.

The file-format description misses some points to write a parser for it. In my opinion referencing on "INI like" file formats or on Pythons Config-Parser compatibility isn't enough to define a cross-platform file-format usable by all kinds of tools.

I therefore propose

  • the creation of a EBNF-Syntax of the Editorconfig-File-Format
  • the creation of an explicit description of the Behavior of the implementation

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

xuhdev commented Nov 8, 2016

Can you point out the ambiguity? I can't see the ambiguity in your description. Also, why is the format not enough to define cross-platform file-format? Please elaborate.

florianb commented Nov 9, 2016

Okay - i probably did not explain well what i am looking for. Currently the whole description of this standard is laid out in several prose text-pieces spread across different pages (mainly [as far as i know] and the wiki).

Defining a machine readable standard is a complex task and i don't want to get this discussion nor the maintenance of this standard becoming overly bloated. But since this file format did become fairly successful, the user base widens. I thought of implementing an editorconfig-parser to be able to lint editorconfig files to gain helpful user-feedback. After digging deeper i stumbled some points which i would solve - if wanted - and this is why i considered posting this proposal.

During investigation i figured out that some things aren't specified in a way which do not leave room for interpretation. Or the other way round the current definition of the editorconfig-format allows no single distinction how things must be interpreted.

The first thing which is ambiguous is the file format. INI-files aren't considered as being standardized like f.e. the JSON file format - there exist various different implementations deserializing values in different ways.

Secondly, the different sources of information as well as the missing description leave a fair amount of room for interpretation to the implementers.
The positive integers of tab_widthas an example, it is good that it is defined, but the range of valid numbers should be defined for every property or in general.

Spaces like this leave room for interpretation what is valid and what is not. It leaves room for unpredictable behavior.
Another example is the current implementation of parsing the indent_size. Having an editorconfig-file defining an indent_size-property returns the tab_width-property (set to the same value), too. Where is this behavior defined?

Don't get me wrong. I am happy having editorconfig and i am full of respect for work being done here. I want to help to take the next step.

I want to help creating the next level of editorconfig-tools, allowing linting, giving predictable feedback about the applied editorconfig-files, granting a conform user experience spread over all platforms and tools being used to manage editable files.

In my opinion, defining a strict, explicit and exhaustive grammar for editorconfig files, describing explicitly what which tool should do with defined properties would add determinism to this standard. And would tighten the definition in general.


👍 I agree that we should make the format more explicit and I think a formal grammar would be a great first step.

Here are two issues with more discussion on this topic: #97 and #98.

I'm +1 on an EBNF definition and a detailed description of the behavior.


I would also like to add that this specification in my eyes should (and easily could) be backwards-compatible to the majority of existing INI-parsers and editorconfig-implementations.

We can make it also easily extensible as future demands like #228 effort it. Other than it it is suggested in that thread, i think we should avoid introducing a "breaking" file-format to achieve that goals. It would come with a tremendous amount of work and surely will distract a lot of users.

Hovever, the dot-file-mess let's me think about a new .dotless-file-type catching them all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment