editorconfig / editorconfig-core-java

Clone of EditorConfig core written in Java

This repository is placeholder used for issue tracking for format issues and other universal EditorConfig issues, as well as the wiki pages.

editorconfig-core-java's Issues

EditorConfig validator: support for line/column, offset info with ParsingException

It should be cool if we could have an utility method validate which waits a String content of an editorconfig and throws ParsingException when this content is not well formatted:

public class  EditorConfig {

....
  public void validate(String editorConfigContent) throws ParsingException {
    // here parse editorConfigContent and throws ParsingException  with line/column, offset info
  }
}

Here a sample with miss of close of [ for section names:

[*]
charset = utf-8

[*.md // <- here there is an error because section is not closed

The exception ParsingException should contains offset and line/column info where there is an error.

With this utility method validate, any IDE could support validation with marker.

Many thanks!

Inconsistent Java-Version

The Readme.md says:

Prerequisistes: Java 7

but the pom.xml contains:

<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>

Paths with native Windows separator \ don't seem to be matched properly.

I'm working on Windows and tried to use gradle-eclipseconfig to manage charset settings in Eclipse project managed by Gradle. The examples provided by the project didn't work and I think I finally found the problem in the fact that the plugin forwards native paths to EditorConfig. While EditorConfig seems to have some recognition of \ in section-globs, it doesn't seem to normalize paths to match in the end. So the simple section [*] doesn't match Windows paths.

Have a look at the following debugging output:

11:01:56.533 [ERROR] [org.gradle.api.Project] C:\[...]\Dummy.java -> C:/[...]/Dummy.java
11:01:56.535 [ERROR] [system.err] .*/[^/]*
11:01:56.538 [ERROR] [system.err] .*/[^/]*
11:01:56.538 [ERROR] [org.gradle.api.Project] [:] -> [charset:utf-8, trim_trailing_whitespace:true, indent_style:space, indent_size:2, tab_width:2]
11:01:56.543 [ERROR] [system.err] .*/[^/]*

The outputs on STDERR are from EditorConfig by setting the following on the shell:

set JAVA_OPTS=-Deditorconfig.debug=true

These are the regular expressions matched against the paths and as you can see, those are using / instead of \ always with my very simple section. In my opinion, before matching the file paths those should be normalized to correspond with whatever is used in the patterns as separator.

https://github.com/editorconfig/editorconfig-core-java/blob/master/src/main/java/org/editorconfig/core/EditorConfig.java#L242

Activate Travis CI hook

Travis CI descriptor to run the core tests was added in 10c8d1f. The Travis CI hook needs to be activated by some of the repo owners in https://github.com/editorconfig/editorconfig-core-java/settings/hooks

Isn't a list of pairs a map?

Isn't a list of pairs a map? Shouldn't List<EditorConfig.OutPair> types be maps?

Perform the first Maven release

Not being sure at all how deep is the Maven knowledge here in editorconfig-core-java community, I am listing the steps necessary to perform the first Maven release.

(0) We should decide who will be the release engineer. Some of the project owners seems to be the most natural choice. I am ready to take the role too. Ideally, at least two community members should be able to release.

(1) Initial setup of our OSSRH Maven repository: http://central.sonatype.org/pages/ossrh-guide.html

(1.1) The release engineer needs to create a Jira account on Sonatype Jira: https://issues.sonatype.org/secure/Signup!default.jspa

(1.2) The release engineer needs to create a new project ticket that will be processed manually at Sonatype: https://issues.sonatype.org/secure/CreateIssue.jspa?issuetype=21&pid=10134

(2) Our project needs to comply with Maven Central Requirements http://central.sonatype.org/pages/requirements.html such as GPG/PGP signing, supplying Javadoc and Sources, etc.

(3) The release engineer needs to release.

java.nio.file.Path support?

If Path was taken instead of a String then custom filesystems could be used.