Fix file pattern to work like .gitignore files

[treyhunner]

The following 3 bullet points from the .gitignore manpage should apply to editorconfig file matching as well.

• If the pattern does not contain a slash /, git treats it as a shellglob pattern and checks for a match against the pathname relative to the location of the .gitignore file (relative to the toplevel of the work tree if not from a .gitignore file).
• Otherwise, git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, "Documentation/*.html" matches "Documentation/git.html" but not "Documentation/ppc/ppc.html" or "tools/perf/Documentation/perf.html".
• A leading slash matches the beginning of the pathname. For example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".

The vim globpath command should be used instead of glob because it works similarly to fnmatch.

[xuhdev]

Instead of writing file parsing code for each editor as a plugin, I think, it is better to write a separate program for file parsing. Editor plugins would try to call this program to get the file parsed and the plugin is informed of what should be done. This would make us write less code on file parsing, and we would have much more choices for regular expression and other file parsing elements. What do you think?

[treyhunner]

It would be nice to making everything as native to the plugin environment as possible, but I like your idea for the sake of code reuse. If we do choose this route then we should probably make this parser as portable as possible. We could always package the plugins with a binary version of the parser though.

Issue #2 on the main editorconfig project also relates to file parsing.

[xuhdev]

I think, to write this program in a common language, such as C, C++, Java, or something else, is appropriate. After this external program parses the .editorconfig file, it send the parsing result to the editor plugin in a pipe (or something similar). So, I think it's time for us to choose the language of the external program and the structure of the parser. Do you think so?

[treyhunner]

I'd choose C due to the low overhead of a compiled binary file, but I'm not sure whether we'd end up with library inconsistencies between Windows/Linux/Mac (for example regex.h).

As for the structure of the parser, I may hack something together in pseudo-code or Python as an example of how I expect the parser to work and then re-implement in the language of choice from there.

Do you think we should develop the parser in the main editorconfig project (since the code will presumably be shared by all plugins)?

[xuhdev]

For regex, You may consider pcre

The parser, I think, a simple format of ini or xml is enough for early development. Then lua could be considered as a complex format. We could embed lua interpreter into our parser. Lua interpreter is very small and suitable for our case, since we do not need as much features as python interpreter has.

I agree, we should develop the parser In the main editorconfig project.

[treyhunner]

We may not need anything beyond an INI parser (this one maybe) and fnmatch (Darwin version looks simple enough).

What's the benefit of using lua?

[treyhunner]

@xuhdev, let's move the discussion to issue #3 on editorconfig project.