Clarify behavior of ; and # within values about specification

[florianb]

@MichaelKetting you might have noticed we merged a change to the specification explicitly disallow inline comments in the ini-parsing for EditorConfig. The next step will be aligining the EditorConfig parsers out there.

[jednano]

Oh, right. I think that @florianb and I agreed that that particular rule wasn’t ideal, but we should probably have had the spec align with current implementations.

[florianb]

Thank you very much for pinging me @MichaelKetting – you are absolutely right. What a pity.

@editorconfig/board-member Regarding this case and the thoughts we already put into a rework/creation of a ini grammar are there any objections to try remove inline comments in general?

I think introducing a viable escape mechanism would be a second option, though I think it would be more ergonomic to try to abandon inline comments at first.

Given there are no objections i'd try to push this forward including taking on Jed's work at the spec PR #29 . Thank you all very much.

[sharwell]

I meant to create this in https://github.com/editorconfig/specification. Can someone with permissions for both repositories use the Transfer Issue feature to move it?

[xuhdev]

This seems like an oversight in the spec language (#12) that none of us happened to catch. @jedmao Do you recall anything regarding this?

[jednano]

This wasn't an oversight. I thought it was a bit of a silly rule, but preserved it because of the existing tests that were mentioned above.

[xuhdev]

@jedmao I don't think the language preserves the existing tests though. The current test says that if you have a colon after a value, it should be taken as part of the value. The language says that it shouldn't be taken as part of the value, at least for now.

[florianb]

Yeah - i can't recall the full discussion, yet,

But we skipped support for inline comments for the revision of ini parsing and specification entirely because of it's ambiguity.

I agree we should change the spec.

[MichaelKetting]

@florianb This ticket's been in limbo since March 2021. Do you have an update about the status of spec? Not being able to use semi-colons in string values of editor.config prevents some powerful usage scenarios from moving forward.

Much appriciated, Michael

[xuhdev]

@florianb No objection from my side.

[xuhdev]

@florianb #29 is only a clarification PR -- it doesn't require any changes related to the tests. I think it's safe to approve and merge if you agree with the changes in #29 .

[florianb]

Yeah thanks @xuhdev – i thought waiting some days for response may have gained more feedback. 😅

[cxw42]

Following up --- it looks like #29 and editorconfig/editorconfig-vote#6 are contradictory on the surface. To help out dotnet/roslyn#44596 , could we define it one way or the other?

Edit Would it make sense to open an issue in editorconfig/editorconfig asking for votes about whether people expect ; and # in a value to start a comment or not?

[xuhdev]

Following up --- it looks like #29 and editorconfig/editorconfig-vote#6 are contradictory on the surface. To help out dotnet/roslyn#44596 , could we define it one way or the other?

@cxw42 The reason those two are contradicted is that the poll happened later than #29, and we decide to go the way as the poll has decided.

Edit Would it make sense to open an issue in editorconfig/editorconfig asking for votes about whether people expect ; and # in a value to start a comment or not?

That would be a useful survey, but I don't think it's worth the effort to massively change the behavior (which is not really a particularly groundbreaking feature any way)