Clarify behavior of formatting (non-"root") properties at top level about specification

[jednano]

Now to answer the OP, I think we should stick with what he said:

Any property other than root MUST be located under a section to take effect. They are not otherwise recognized.

And don't do any of the default [*] stuff.

[cxw42]

I agree with updating the spec to clarify the current behaviour. I agree that implicit [*] would be more ergonomic, but I personally think we would need to more clearly define our versioning scheme before making such a significant change! Edit Specifically, I think we would need a way for cores or plugins to provide a meaningful error message when encountering an unsupported feature. E.g., perhaps a root version property. However, that would be a separate issue.

[xuhdev]

OK, sounds good to me.

[jednano]

To be clear, the EditorConfig INI parser allows you to specify any/all custom properties that you want. Some people actually use this for their own custom implementations outside of EditorConfig. root=true is the only root property that EditorConfig does anything with, but I don't know if invalid is the right word to use if a property that is not root=true is at the root level.

That said, I also very much agree that we need more clarification and less ambiguity about these things and I'm actively working on that very goal during my international travels. I hope at least we can make one step forward on this.

[xuhdev]

It doesn't sound right to me to put any other settings on root. Do we have statistics on what we do right now?

[jednano]

@xuhdev for the purposes of EditorConfig, you're right. That's all we would ever need or support. But for anyone outside of EditorConfig who is perhps using the config inheritance feature of EditorConfig, there's nothing stopping them from defining custom properties at the root level.

This is another reason why I think it's important to distinguish between:

1. The actual INI parsing and only the INI parsing. No rule restrictions at root or within sections.
2. Supporting EditorConfig-specific rules.
3. The inheritance feature.

These are all very different things and I can see non-EditorConfig implementations that rely upon 1 & 3, but not 2.

[xuhdev]

I think whether an assignment not under any section is a matter of syntactic definition. If we allow any anything other than root outside any section, we would be essentially repeating the functionality of [*]. I don't see any reason to duplicate this functionality twice. But I agree we should make this point clear.

Currently, as far as I see, the C core does not output anything not in any sections.

[jednano]

You're right. It doesn't look like the js core does either.

root = true
foo = bar

[*]
qux = corge

The output was just qux=corge.

I think the INI parser should definitely record those properties at root though. Whether we do anything with them is another story.

[xuhdev]

I'm not sure whether there's any benefit to break with the existing behavior and output properties at root. I'm personally leaning toward clarifying this existing behavior rather than altering it.

[jednano]

To be clear, I'm not suggesting we output, change or break anything with respect to the existing EditorConfig implementation. I'm saying that the INI parsing aspect of EditorConfig can be decoupled into a separate parser that knows nothing about EditorConfig's rules and especially nothing about root=true or any of the merging strategy.

As it doesn't know anything about root=true, it doesn't make sense to impose this artificial limitation of only having one property in the default/root section. Once an EditorConfig core gets its hands on this AST provided by the parser, then it can ignore the unsupported rules or even throw validation errors at that point, if we decide to go that route.

The point is, we can keep the INI parsing as agnostic to implementation as possible and put EditorConfig-specific "business logic" into the cores instead of the INI parser itself.