Allow multiple entries in section names

[myss]

Currently we can have only one pattern in section names. But sometimes, to avoid repetition, it would be more useful to allow multiple patterns. The patterns could be separated by |, which is a character not allowed in file names.

Example:

[*.cpp|*.h|*.c|*.java]
indent_style=tab
indent_size = 4

[treyhunner]

I have only two objections:

1. This won't be backwards compatible with existing plugins (this is not necessarily an issue if we don't encourage its use until later versions)
2. This would further separate our glob matching from traditional filename glob matchers. This may not necessarily be an issue, but it would mean that every EditorConfig library/tool that uses glob matching must use or implement a custom INI parser and glob matcher for EditorConfig.

In general I really like this idea. I find that this is a common use case:

[*.html|*.js|*.css]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

[xuhdev]

I do think that it is great to have multiple patterns in a section name. But this way will break the compatibility (@treyhunner This won't break the plugin compatibility, but break the previous .editorconfig files I think). I have an idea, what about this format:

[*.html] [*.js] [*.css]
indent_style = space
indent_size = 2

What do you think?

[treyhunner]

@xuhdev this will break compatibility for previous core libraries which means new .editorconfig files using this feature would not work for users who have not upgraded their EditorConfig core library version.

@myss | is actually a valid character in file names so this could break existing .editorconfig files, but I doubt any files match based on that symbol being in the file name.

Do you think we should add support for this feature in the next core library release so the support will be there in the future when we encourage the use of this option?

The format @xuhdev mentioned is interesting, but I think I prefer the |-separated format suggested by @myss better.

[xuhdev]

@treyhunner
The compatibility we should keep, in my opinion, is that our library should always keep compatibility with older version of the file format, but not make the old version to be compatible with later versions. When users are writing a .editorconfig file, he should understand which version is the least rerequired version.

If no one is using | as the file name, we can use this format I think.

[sindresorhus]

Can't you just use brace expansion?

[*.{html,js,css}]
indent_style = space
indent_size = 2

[treyhunner]

@sindresorhus I have never seen that notation before. What languages/technologies use that convention?

[sindresorhus]

I only use it in bash and glob Node.js module, but I'm sure there are more.

[treyhunner]

I just committed changes to the Python core to add support for curly brace expansion (editorconfig/editorconfig-core-py@e4807b1 and editorconfig/editorconfig-core-py@bef6cc5). It should work similarly to node's minimatch module currently (though not quite the same).

Now we need some tests written and the C core library still needs to be changed.

[xuhdev]

Nice to hear this. I'll make some changes when I have some free time.

[treyhunner]

This feature is now live in the EditorConfig Python core version 0.11.0 which is on PyPI.

The C core is finished also but the various EditorConfig plugins still need to be updated to use the new core library versions.

[xuhdev]

No plugin code needs to be updated. They just need to be compiled against the new core library. So this could be done very soon.

[treyhunner]

You're correct. That's what I meant to state.

I'm closing this issue as resolved.

[franleplant]

@sindresorhus {} notation rocks!

Can we add the example you gave to EditorConfig's doc example?

Can't you just use brace expansion?

[*.{html,js,css}]
indent_style = space
indent_size = 2

[sindresorhus]

PR welcome for improvements to the docs: https://github.com/editorconfig/editorconfig.github.com

[franleplant]

Great @sindresorhus, will do!
Thanks!