EditorConfig - Alone Settings for All Editors / IDE

EditorConfig is a configuration file and a set of extensions, to a large number of code editors and IDEs (Next, just IDE).

His task is to create a single format of settings, and, once and for all, solve issues like “tabs or spaces” for all IDEs and all programming languages. Such a file can be stored in the project version control system, which allows all its developers to use the same configuration.

.editorconfig files can be found in projects such as jQuery , Ruby , WordPress , and many others .

Plugins are available for a large number of IDE
')



Let's see how this works.

EditorConfig?

Here is an example .editorconfig file that defines indentation rules for Python and JavaScript code:

 ##            . ##  "ini"       ,    . ##   ,    -    . # #   EditorConfig root = true #     unix-   [*] end_of_line = lf insert_final_newline = true #   4  [*.py] indent_style = space indent_size = 4 #     (  ) [*.js] indent_style = tab #     js    lib [lib/**.js] indent_style = space indent_size = 2 #    package.json or .travis.yml [{package.json,.travis.yml}] indent_style = space indent_size = 2 

EditorConfig files use a slightly modified INI format.
Each .editorconfig must be in UTF-8 encoding, and at the end of the lines must be either
CRLF or LF .

The section name is the file mask, for example [*.js] or [index.html] .

Unlike the usual .ini format, you can use [ and ] in the section name, which allows you to specify a list of characters, one of which should be in the specified position. For example, valid constructs like this: [file[123].js] . How it works - read below.

Each comment should be on a separate line and begin with ; or # .

* - (/)

Example: [* .js]
hello.js // Coincidence
hellojs // No match
index.html // No match
lib/source.js // No match

** -

Example: [**. Js]
hello.js // Coincidence
hellojs // No match
index.html // No match
lib/source.js // Coincidence

? -

Example: [hell? .Js]
hello.js // Coincidence
hell.js // No match

[name] - “name”

Example: [[abc] .js]
a.js // Coincidence
b.js // Coincidence
abc.js // No match

[!name] - “name”

Example: [file [! 2468] .js]
file1.js // Match
file2.js // No match

{s1,s2,s3} -

Example: [index. {Js, html}]
index.js // Coincidence
index.html // Coincidence
package.json // No match

\ -

Example: [\ [abc \]. Js]
a.js // No match
[abc] .js // Coincidence

?

Editor config strives to be language independent and work in all IDEs. Unfortunately, this is not always possible, so some of the plugins do not support all the settings. More details can be found on the page of each plugin in github.

All settings are case insensitive.

indent_style

Values: tab, space
Allows you to set a hard or soft tab for indents.

indent_size

Values: Number
Allows you to set the indent width using soft tabs.

tab_width

Values: Number
Allows you to set the indentation width using hard tabs. If not specified, take the value from indent_size.

end_of_line

Values: lf, cr, crlf
Allows you to choose what to use at the ends of lines.

charset

Values: latin1, utf-8, utf-8-bom, utf-16be, utf-16le
Allows you to select encoding for files.
Using utf-8-bom is not recommended.

trim_trailing_whitespace

Values: true, false
Allows you to remove spaces from the ends of lines.

insert_final_newline

Values: true, false
Allows you to make sure that at the end of the file there will always be a new line.

root

Values: true, false
A special setting that should be at the very top of the config. If set to true, the parser will not search for other configs of the parent folders (details below).

Ignore

Some files, such as third-party libraries or minifitsirovannye files, it is better not to touch. In such cases, any setting can be set to ignore . For example:

 #    JS  CSS [*.{js,css}] indent_style = space indent_size = 2 #     JS  CSS . [*.min.*] indent_style = ignore trim_trailing_whitespace = false insert_final_newline = ignore 

?

The original task of EditorConfig is to create a minimal set of properties that would work in all of the main IDEs.

The task is not easy, for example, let's consider the possibility of adding a setting that would limit the width of the line: max_line_length
To add this setting, you need to solve a few questions:

• Make sure all editors / IDEs support it.
• Decide whether to use hard or soft (when the line physically remains long, but looks like two) transfer, or allow the user to select it by adding another setting (not all editors / IDE support both types of transfer)
  
• If you use a hard port, then what to do with languages ​​where a hard port can break the code? (for example HAML)

Currently, the max_line_length property exists, but only works in vim .

EditorConfig

If a program that uses EditorConfig encounters an unfamiliar setting, it should ignore it. This allows you to make the format extensible and not limited to standard settings.

There are two areas for development:

/IDE

Some editors / IDEs have their own characteristics, for example, in jEdit, the set of encodings is larger, therefore there is a jedit_charset setting that only works for jedit.

/

Third-party programs and plug-ins can extend EditorConfig and add settings that will only work for specific languages ​​or file extensions.

For example, the npm CodePainter module, which uses EditorConfig as a configuration file, allows you to select quotes (single or double) to be used for strings (qoute_type), or place spaces inside the brackets (spaces_in_brackets). But all this will work only for javascript.

Also, the developers have in their plans a whole set of possible settings that may be used in the future, for example:

curly_bracket_next_line

Sets the transfer of curly braces to the next line, for languages ​​where it is

java_class_path

Can be used by other plugins.

language

Allows you to set the language by file extension. This can help when templating engines, such as Jinja2 , use .html files.

Full list can be found here (eng.)

?

When the plugin will need to calculate the configuration for the file, it will go up through the file tree, from the directory with the file to the root, and load the settings from each .editorconfig file on the way.
The priority of settings in configs closer to the file is higher.

For a file with this path: /Users/username/code/project/main.js , the plugin will look for the .editorconfig file in the .editorconfig places:

 /Users/username/code/project/.editorconfig /Users/username/code/.editorconfig /Users/username/.editorconfig /Users/.editorconfig /.editorconfig 

You can stop the search by setting root=true in one of the configs on the path.

Such a structure allows, for example, creating .editorconfig in a user folder and thus obtaining the default settings for all projects, and, if necessary, rewriting these settings a few levels higher.

?

When the parser reads the .editorconfig file, it gives higher priority to the settings that are below.
The authors created a small demo [Which at the moment, as noted by KindDragon , a bit buggy when calculating the paths], where you can play around with the format and see the result

EditorConfig plugins are designed in such a way that they change the IDE settings depending on the open file. Sometimes you have to use undocumented or unusual IDE features. Because of this, formatting is applied only when saving files, and if you want to use EditorConfig with already existing code, you will have to use one of the tools below.

editorconfig-tools [ github ]

A set of tools for checking and reformatting code. It is at an early stage of development and is not yet very stable.

ECLint [ github ]

It is similar in functionality to editorconfig-tools, but, in addition, can analyze existing code and generate an .editorconfig file. Also under development.

CodePainter [ github , npm ]

Uses .editorconfig , but works only with JavaScript code.
It has special settings for JS code.

, ?

To help plug-in creators, a set of core components (cores) has been created that can be used in plug-ins and take on the job of searching and parsing configuration files. At the moment there are versions in C , Java , Python , work is underway on the JavaScript version.

The plugins themselves try to overwrite the corresponding IDE settings instead of formatting themselves.

Unfortunately, there are still no plug-ins for IDEs such as Eclipse or NetBeans, their architecture does not allow you to easily change the settings.

If there is someone among the readers who is ready to start creating plug-ins, here is a good idea how to get started (eng.)

Windows

To create an .editorconfig file in Windows Explorer, you need to create a file called .editorconfig. and Windows Explorer will rename it to .editorconfig .

The EditorConfig team did an excellent job, but there are still a lot of difficulties, interesting tasks and solutions:

• Writing and plugin support for lesser known IDEs.
• Development of kernels for plug-ins in other languages ​​and refinement of current
• Expanding functionality and adding new settings
• Refinement of existing solutions for code transformation

If any readers would be interested in participating in the project, these are good ways to get in touch with the developers (all in English):

• Google Groups .
• Wiki
• Bugtracker
• The EditorConfig IRC channel on FreeNode was also created, but it is still half empty.

I am not in the project team, but I use .editorconfig myself and will gladly pass on your suggestions and wishes - write to personal mail.