.editorconfig file_header_template: can't use # (or ;) symbol

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

It doesn't seem to be possible to use a # symbol in file_header_template, without it being parsed as a comment (escaping using \ doesn't appear to work).

This is annoying when trying to include the text C#.

---

Original Comments

Visual Studio Feedback System on 5/22/2020, 01:29 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Antony.Male on 5/22/2020, 01:35 AM:

This was closed as "applies to Crystal Reports".

This is very much about Visual Studio. `file_header_template` was proposed [here](https://github.com//issues/33012) and implemented [here](https://github.com//pull/41982). .editorconfig is documented [here](https://docs.microsoft.com/en-us/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019).

Cyrus told me to open an issue here rather than in dotnet/roslyn.

Visual Studio Feedback System on 5/27/2020, 09:53 AM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.

---

Original Solutions

Antony.Male solved on 5/22/2020, 01:31 AM, 0 votes:

[Removed]

[sharwell]

@agocke any thoughts on how we might approach this?

[wvdvegt]

Please add semicolons to this issue as well. file_header_template text is truncated after such character.

[sharwell]

📝 Make sure to update the handling for CompilerVisibleProperty (global editorconfig) once the escape sequence here is determined.

[304NotModified]

@sharwell

Please add the bug label. It's clearly a bug if you check the specs.

[304NotModified]

Is there a hint where to fix this?

[jmarolf]

@304NotModified can you point me to the editorconfig spec you are working off of?

[sharwell]

@304NotModified This is not clearly a bug; there contradictory rules here. The EditorConfig specification explicitly states that a # or ; is not parsed as part of a value:

Inserting a # or ; after non-whitespace characters in a line (i.e., inline) shall neither be parsed as a comment nor as part of the section name, pair (defined below) key or value in which it was inserted. This may change in the future; thus, is not recommended.

However, the test suite does exactly the opposite:

https://github.com/editorconfig/editorconfig-core-test/blob/70840cfaf6a06766ab61e975b8a1fe3b891ee08e/parser/comments.in#L14-L16

Currently Roslyn treats the formal specification as the source of truth, with the test suite currently demonstrating a failure to adhere to that specification.

[304NotModified]

Wow! Yes I have read indeed https://editorconfig-specification.readthedocs.io/#file-format

So this is probably hard to send a PR for?

[sharwell]

Personally, I would prefer the interpretation that the tests use, but I expect it would be considered a breaking change for the compiler so I'm not sure what it would take to change.

[MichaelKetting]

@sharwell do you have an update about the status of this ticket? The pr #51625 and the ticket in editorconfig/specification#23 are all in limbo since March 2021. Not being able to use semi-colons in the file_header_template setting breaks this feature for license header usage since for instance the LGPL has them in its standard text.

Much appriciated, Michael

[florianb]

Thanks to the initiative of @MichaelKetting we changed the wording of the EditorConfig specification regarding inline Ini comments as follows:

Inserting an unescaped # or ; after non-whitespace characters in a line (i.e. inline) is not parsed as a comment, nor as part of the section name, the key pair (see below), or the value it was inserted into. This behavior may change in the future; therefore this kind of insertion is not recommended.

This was hopefully the needed step to fix this issue in a compliant way.

[rurounijones]

Any update on this? I have run into this issue trying to add GNU license information where everything after the ; gets cut off when adding headers in Visual Studio.

[CyrusNajmabadi]

@sharwell looks like the editorconfig group addressed this confusion. Could a community member contribute a fix here?

[sharwell]

@CyrusNajmabadi This is still waiting for clarification, as the specification remains ambiguous:
editorconfig/specification#29 (comment)

[cxw42]

I help out with EditorConfig and am participating in the discussion of this issue. Would this spec change meet your needs if accepted?---

(Draft --- not yet part of the spec)

A ; or # anywhere other than at the beginning of a line does not start a comment, but is part of the text of that line. E.g.,

[*.txt]
foo = editorconfig ;)

gives variable foo the value editorconfig ;) in *.txt files, not the value editorconfig.

This specification does not define any "escaping" mechanism for ; or # characters.

[rurounijones]

It would for me. Thank you for looking into it.

[cxw42]

EditorConfig specification v0.15.0 is now live, and removes comments from values: https://editorconfig-specification.readthedocs.io/#no-inline-comments. I think this should finally resolve the question! 🤞

[ghost]

Now the specification is clear, any word on when this issue will be fixed in VS 2022?

[CyrusNajmabadi]

@paytools-uk This is on our backlog, so no timeline on a fix. If you are interested in seeing this changed, we would likely accept a reasonable-sized/scoped community contribution here. Thanks!

[ghost]

Thanks – happy to take a look – can you point me at the appropriate repo/project?

[CyrusNajmabadi]

@paytools-uk Possibly https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/CommandLine/AnalyzerConfig.cs

[DanFTRX]

With the spec now not including comments on the same lines as key value pairs, is the change the team is looking for just updating the regex or is there a more complex solution needed for a reason unclear to me?