Thanks @MyklClason for start working on this.

Instead of reusing the extension field and picking the best extension I would an extra field called path_matches that is a regex that should match the filename (doing some normalization for path separators).

I think this is more general and does not abuse the extension concept.

As for the extension abuse. I completely agree it's abuse. I wasn't sure on what to call it offhand. I'll use these names instead.

_best_match_extension => _best_match
_possible_extensions  => _possible_matches
ext(s)                => match(es)

My regex is weak so I was unable to create a regex that could duplicate the functionality of _possible_extensions (_possible_matches). That being said, it does seem trivial to use config directly to auto-build a regex in the format of (.html|.xml|pattern|...). For now, I'll just implement a basic version that won't break any tests. Full integration will require a bit of re-writing as it'll require switching fully from extensions to file names. Including various changes to the config file and linters.py. For now I've left it as using the "best match" approach rather than using multiple sets of linters.

Note:
This method may become problematic down the road as the number of linters increase due to regex build times. Memoization will help some, but may not be enough.

Regex worked out rather well, but ended up having to write a priority function to get the expected results. I'm also not sure the regex is efficient.

Edit: I'm not sure why this is failing. Seems like json.json is valid and should be parsed as .json.
Edit2: Seems like the test data might be bad if nonewerror.json is supposed to be error-free as GitHub and the linter shows it having an error. Though it's odd that there's an error in Python 2.7 only.

Also out of curiosity, why are you using import gitlint.utils as utils instead of simply import utils?

I ask because I end up commenting out that line whenever I'm testing this. Here is what I'm using (rather simple approach). Before when I was working with Python, I normally don't use the terminal, but using Cloud9 as my IDE these days.

root/gitlint $ python -c 'import linters; print linters._best_match("a",{".a":1,".b":2,".c":3,".b.c":5,"a":0})'

I meant something different.

Instead of reutilizing the extension field in the configuration, I would add an extra field called path_matches, which is a regex.

Then when parsing the config instead of returning a dict that maps from extension to linter you return a Config object, which has a method called get_linters(filename).

Then in the lint function instead of for linter in config[ext]: you do for linter in config.get_linters(filename):.

For example if you want to run a linter for travis.yml files you would have:

travis:
  path_matches: "/\\.travis\\.yml$"
  ...

Ah yes. I had similar thoughts while I was working on it, in terms of how to adjust the config. I was actually thinking of using something exactly like config.get_linters(filename), but it seems like that should get all linters, thus I didn't use it since I was still in the best match mindset.

As a potential issue, it brings up the question of things like, "What if there's say a config.js file that uses a specialized version of javascript? That method results in using both config.js and .js, which may not be good." Prioritization of the results of the regexes seems to solve that, perhaps with a command to switch between best match linter and all matches linter. That and to do it right, I'd have to make a number of changes that break tests, which I may or may not be able to fix. Such as changing the below error message to something like no linter defined or enabled for filename, "%s" % filename, but I could probably handle that much.

'skipped': ['no linter is defined or enabled for files'
                            ' with extension "%s"' % ext]

For backwards compatibility and perhaps simplification, it might be good to still use extensions. Essentially, if path_matches isn't provided, then an extension matching regex will be generated from the extensions.

Still though, seems good to move the get_linters aspect to the config file. I'll do that in about a day.