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

vsfeedback commented 4 years ago

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/dotnet/roslyn/issues/33012) and implemented [here](https://github.com/dotnet/roslyn/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 commented 4 years ago

@agocke any thoughts on how we might approach this?

wvdvegt commented 4 years ago

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

sharwell commented 4 years ago

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

304NotModified commented 3 years ago

@sharwell

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

304NotModified commented 3 years ago

Is there a hint where to fix this?

jmarolf commented 3 years ago

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

sharwell commented 3 years ago

@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 commented 3 years ago

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

So this is probably hard to send a PR for?

sharwell commented 3 years ago

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 commented 2 years ago

@sharwell do you have an update about the status of this ticket? The pr #51625 and the ticket in https://github.com/editorconfig/specification/issues/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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

sharwell commented 2 years ago

@CyrusNajmabadi This is still waiting for clarification, as the specification remains ambiguous: https://github.com/editorconfig/specification/pull/29#discussion_r783382976

cxw42 commented 2 years ago

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 commented 2 years ago

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

cxw42 commented 1 year ago

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! :crossed_fingers:

ghost commented 1 year ago

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

CyrusNajmabadi commented 1 year ago

@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 commented 1 year ago

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

CyrusNajmabadi commented 1 year ago

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

DanFTRX commented 8 months ago

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?

dotnet / roslyn