It turns out that in many config files within a project of ours, empty values are normal and do not cause issues with our IDE's so we'd like our linter to mirror this if possible.

Proposal

Enable empty values to be parsed as empty lines or pairs behind a feature flag so callers can decide what level of enforcement they get.

Hello, I am currently an employee at Microsoft. We would like to use this library for a large project; however, we would like to have a caching layer to not have to parse the .editorconfig file(s) every time we are using them. Is this something you would entertain as an open-source contribution?

Expected Behavior

Given a section header

[/*] # only root files
end_of_line = lf

The editorconfig file should parse and return LF as the EOL rule for files at the current directory with the config file.

Actual Behavior

Because of the strip_suffix behavior, if a section header doesn't end with ] the line will be considered invalid.

Precedent

We're migrating from https://github.com/editorconfig/editorconfig-core-net as the underlying EC parser, and discovered that running a new linter using ec4rs breaks on our existing .editorconfig files. While fixing the files is totally possible, the INI syntax one gets in VSCode suggests that the comment after a header is in fact highlighted as a comment and you would expect it to be ignored the same way trailing comments are in many formats like YAML and TOML.

Attempting to parse a valid EditorConfig file that has a UTF-8 BOM results in an ec4rs::Error of "invalid line".

This is an issue that should be handled early on in the IO. In our consuming project we handle files of ASCII, UTF-8, UTF-8-BOM, UTF-16-[BE|LE] by having our own small FileContent abstraction. Something similar may be useful here/there may be a crate for this already but we didn't fine a simple one we liked and it's not much code.

I can work on contributing a fix for this soon.