Skip to content

Add here-string autoClosingPairs to PowerShell language configuration - #5545

Draft
Andy Jordan (andyleejordan) with Copilot wants to merge 3 commits into
mainfrom
copilot/here-string-intellisense-fix
Draft

Add here-string autoClosingPairs to PowerShell language configuration#5545
Andy Jordan (andyleejordan) with Copilot wants to merge 3 commits into
mainfrom
copilot/here-string-intellisense-fix

Conversation

Copilot AI commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

PowerShell here-strings (@'...'@, @"..."@) were not auto-closed by the editor — typing @" would not insert the closing "@ on a new line.

This was fixed upstream in VS Code core via microsoft/vscode#95245, which added here-string entries to the built-in PowerShell language-configuration.json. This PR mirrors that fix explicitly in the extension's setLanguageConfiguration call so the behavior is self-documenting and not silently dependent on the VS Code version.

Changes

  • src/extension.ts: Adds autoClosingPairs to the setLanguageConfiguration call, including:
    • @'\n'@ and @"\n"@ with notIn: ["string", "comment"] — matches the VS Code core fix exactly; \n is required because PowerShell's here-string terminator must be at the start of a line
    • All pre-existing auto-closing pairs ({}, [], (), "", '', <##>) carried forward explicitly, since specifying autoClosingPairs replaces rather than merges with the built-in configuration

Closes #1517

VS Code PR microsoft/vscode#95245 added autoclosing pairs for PowerShell
here-strings to VS Code's built-in language configuration. This change
explicitly adds the same pairs to the extension's setLanguageConfiguration
call so the behavior is self-documenting and works correctly regardless of
the VS Code version.
Copilot AI changed the title [WIP] Fix here string intellisense completion and indentation Add here-string autoClosingPairs to PowerShell language configuration Jun 29, 2026
@andyleejordan

Copy link
Copy Markdown
Member

Copilot does this actually need to be added to our extension or can we just close as resolved since users will always pick up the changes from upstream?

…Code core

The fix from microsoft/vscode#95245 (merged April 2020) is already present in
every VS Code version ≥1.45. The extension's minimum required version is
^1.114.0, so all users already pick up the here-string autoclosing behavior
from VS Code's built-in PowerShell language-configuration.json.

Additionally, setLanguageConfiguration() only replaces keys explicitly
provided; since `autoClosingPairs` was never specified in the extension's
call, VS Code's built-in pairs (including the here-string entries) were
never overridden. The explicit addition was therefore redundant.

Closes #1517

Co-authored-by: andyleejordan <2226434+andyleejordan@users.noreply.github.com>

Copilot AI commented Aug 12, 2026

Copy link
Copy Markdown
Contributor Author

Copilot does this actually need to be added to our extension or can we just close as resolved since users will always pick up the changes from upstream?

Yes, closing as resolved is the right call. Two reasons:

  1. Minimum VS Code version covers it: The upstream fix (Add PowerShell herestring autoclosing pairs microsoft/vscode#95245) landed in VS Code ~1.45 (April 2020). This extension requires ^1.114.0, so every supported VS Code version already includes the here-string autoClosingPairs in the built-in PowerShell language configuration.

  2. setLanguageConfiguration doesn't wipe unspecified keys: Since the extension's call never included autoClosingPairs, VS Code's built-in pairs (including the here-string entries from the upstream fix) were never overridden — users were already getting the fix automatically.

I've reverted the extension.ts change in this commit: Closes #1517 is in the commit message to close the issue when this PR merges.

@github-actions

Copy link
Copy Markdown
Contributor

Good question! Since microsoft/vscode#95245 is already merged and VS Code's minimum engine version required by this extension is well above the VS Code release that included it, users will always have the upstream fix. There's no functional gap to fill.

The main argument for keeping this explicit in the extension was self-documentation and not being silently dependent on VS Code internals — but that's a style preference rather than a correctness need. I'd lean toward closing this as "no longer needed" to avoid maintaining duplicated configuration that could drift from VS Code core in the future.

If you close it, I'd suggest leaving a note on the original tracking issue (if any) pointing to microsoft/vscode#95245 as the upstream resolution.

Generated by Issue Comment Handler — Intelligent Response Processing for issue #5545 · 26.6 AIC · ⌖ 11.4 AIC · ⊞ 24.7K ·

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-comment-handler.md@2f03fdaafb8c1ae62dfde7e0be762a822a201aeb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants