Warn and quick-fix inline comments in .editorconfig

[Copilot]

The EditorConfig spec does not support inline comments, but they were silently accepted, causing rules to silently break with no visual feedback. For example:

[*.md] # this breaks section matching entirely
indent_style = space #required — this corrupts the value

Changes

• New inlineComment grammar pattern (invalid.illegal.inline-comment.editorconfig) — renders inline #/; comments with a red tint via syntax highlighting
• Included in section patterns — flags inline comments after section headers (after ])
• Included in value patterns — flags inline comments after rule values (after =)
• New EditorConfigDiagnosticsProvider — uses VS Code's languages.createDiagnosticCollection API (no LSP required) to emit Warning-severity diagnostics for inline comments, producing yellow squiggly underlines and Problems panel entries with the message: "Inline comments are not supported in EditorConfig. Move this comment to its own line."
• New EditorConfigCodeActionProvider quick fix — adds a standard VS Code Quick Fix action, "Move inline comment to its own line", that rewrites invalid lines like indent_style = space #required into:

  indent_style = space
  #required

• Shared inline-comment parsing logic — keeps diagnostics and quick-fix behavior in sync for both section headers and property values

Valid line-starting comments (# ... / ; ...) are unaffected; they are matched by the existing comment pattern first and excluded from diagnostic analysis.

[SunsetTechuila]

@copilot Inline comments are red, but how do we show an actual error? Is LSP required for this?

[Copilot]

@copilot Inline comments are red, but how do we show an actual error? Is LSP required for this?

No LSP needed. Added EditorConfigDiagnosticsProvider (commit d762c75) that uses VS Code's languages.createDiagnosticCollection API directly. It parses every .editorconfig document on open/change and emits Warning-severity diagnostics for inline comments — giving yellow squiggly underlines on the offending text and entries in the Problems panel, e.g.:

Inline comments are not supported in EditorConfig. Move this comment to its own line.

The invalid.illegal grammar scope (red syntax tint) is kept alongside it so the warning is visible even before the extension activates.

[SunsetTechuila]

@copilot Do we need to use a regex here? Can't we use invalid.illegal.inline-comment.editorconfig?

[Copilot]

Unfortunately no — VS Code's extension API doesn't expose TextMate grammar token scopes at runtime. The invalid.illegal.inline-comment.editorconfig scope lives entirely inside VS Code's syntax highlighting engine and there's no public API to query what scope a given document position has. So the detection logic must be reimplemented in TypeScript.

I've added a comment (commit 9efd460) directly above the regex to explain this and cross-reference the grammar rule, so it's clear the two are intentionally in sync.

[SunsetTechuila]

@copilot This feels hacky. How does language support work in VSCode in general? How do other language extensions handle syntax errors?

[Copilot]

@copilot This feels hacky. How does language support work in VSCode in general? How do other language extensions handle syntax errors?

In VS Code, language support is usually split like this:

• TextMate grammar / language configuration: coloring, comments, brackets, basic editor behavior
• Diagnostics: either a language server, or extension code calling languages.createDiagnosticCollection(...)
• Rich semantic features: usually a language server or a real parser

Other extensions normally report syntax errors from a parser/validator, not from TextMate scopes. TextMate grammars are mainly for tokenization/highlighting, and VS Code doesn’t expose those scopes back to extensions as a diagnostics API.

So for a small format like .editorconfig, the lightweight options are either:

1. ship custom validation logic in the extension (what this PR does), or
2. add a real parser / LSP layer just to produce diagnostics.

I chose (1) because it keeps the implementation small and matches the rest of this extension’s architecture. If you’d prefer, I can rework it toward a parser-backed validator instead of the current regex-based warning path.

[SunsetTechuila]

We need an LSP

[SunsetTechuila]

@copilot How do error auto-fixes work in VSCode?

Can you implement one that moves inline comments to a new line?

[Copilot]

We need an LSP

Implemented in 8081120 via a standard VS Code CodeActionProvider attached to the inline-comment diagnostic, so the fix shows up in the normal Quick Fix / lightbulb flow without needing a full LSP just for this rule. If we want broader parser-backed validation later, that can still be a follow-up.

@copilot How do error auto-fixes work in VSCode?

...

Implemented in 8081120. VS Code auto-fixes are usually surfaced as code actions tied to diagnostics, and this now adds a Quick Fix titled Move inline comment to its own line for the inline-comment warning. Applying it rewrites lines like indent_style = space # required into:

indent_style = space
# required

It also preserves indentation for indented keys/comments and clears the warning after the edit.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• update.code.visualstudio.com
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node out/test/runTest.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[SunsetTechuila]

@copilot Let's imagine we have an LSP. How do we integrate it into VSCode? Do we need any changes on the side of this extension?

[Copilot]

@copilot Let's imagine we have an LSP. How do we integrate it into VSCode? Do we need any changes on the side of this extension?

Yes — if we moved to an LSP, this extension would need client-side changes.

Concretely, on the VS Code side we would typically:

• add an LSP client dependency such as vscode-languageclient
• ship or reference the server entrypoint/binary
• start the language client from activate() in this extension
• register it for editorconfig documents so diagnostics, code actions, completions, etc. come from the server

What can stay as-is:

• the TextMate grammar and language configuration for coloring/brackets/comments
• any purely editor-side behavior we still want to keep local

So the answer is: yes, this extension would need changes, but mostly around bootstrapping the client and deciding which current providers move behind the LSP versus remain local.

[SunsetTechuila]

@copilot Let's imagine we have an LSP. How do we integrate it into VSCode? Do we need any changes on the side of this extension?

Yes — if we moved to an LSP, this extension would need client-side changes.

Concretely, on the VS Code side we would typically:

• add an LSP client dependency such as vscode-languageclient
• ship or reference the server entrypoint/binary
• start the language client from activate() in this extension
• register it for editorconfig documents so diagnostics, code actions, completions, etc. come from the server

@copilot Don't be that concise. Provide more detailed info

[Copilot]

@copilot Let's imagine we have an LSP. How do we integrate it into VSCode? Do we need any changes on the side of this extension?
...

More detail:

If we introduce an LSP, this repo becomes the VS Code client for that server. We would not replace the whole extension — we would keep the VS Code extension, but change what happens at activation time.

Typical integration looks like this:

• keep the existing package.json language contribution so VS Code still knows .editorconfig is an editorconfig document
• keep the TextMate grammar / language configuration for syntax coloring, brackets, comments, etc.
• add a language client dependency (vscode-languageclient)
• ship a server implementation (often a Node entrypoint in this repo, or an external binary) and start it from the extension’s activate()
• create a LanguageClient with a document selector for { language: 'editorconfig' }
• let the server provide diagnostics, code actions, completion, hover, formatting, etc. over the LSP transport

So yes, there are definitely extension-side changes. The minimum client work is roughly:

1. bootstrap the server process
2. wire up client/server capabilities
3. decide which current features stay local vs move to the server
4. remove duplicated local providers once the LSP owns them

For this specific PR, the likely migration path would be:

• move inline-comment validation into the server
• move the quick fix into server-provided code actions
• stop registering the local diagnostics/code-action providers in src/editorConfigMain.ts once the LSP version is active

What probably stays in the extension even with an LSP:

• grammar/theme scopes
• language configuration
• any VS Code-only UI glue or commands that are not really language analysis

What changes architecturally is that the extension stops computing diagnostics itself and instead becomes the host that launches the server and forwards results into VS Code. VS Code then shows those server results in the same Problems / Quick Fix UI, so from the user’s perspective it feels native.

In practice, the main risk is duplicate behavior during migration. If the extension keeps local diagnostics while the LSP also reports them, users will see duplicate squiggles/code actions. So we would want a clean ownership split: either local providers, or LSP-backed providers for a given feature.

So the short version is: yes, this extension needs changes, but mostly client bootstrap/orchestration changes rather than rewriting the whole extension.