Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

stop parsing symbol only ends at end of line, but pipe character is also acceptable

Offen
#144 6 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
powershell
Bereich
tooling

Rechercherichtung

Start with the PowerShell tmLanguage stop-parsing rule shown in the issue and compare it with the about_Parsing behavior. Verify that parsing ends at a pipe only when the pipe is outside double-quoted constructs, while the existing end-of-line behavior remains unchanged.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Environment
  • Editor and Version: VS Code: 1.26.1
  • Your primary theme: Monokai Dimmed
Issue Description

the stop parsing symbol, --% is set to scope all the way to the end of the line. I thought this was how the symbol worked as well, until I reread the doc on the matter (about_Parsing) and instead, it also can be terminated by the pipe character, but only if the pipe would be outside of any double-quoted constructs, as I have determined.

Its also possible to use environment variable substitution using the CMD `%variable% syntax, but if your environment variable name contains a double-quote, PowerShell processes it first, before the substitution has occurred (if it even occurs, as just like in CMD, if the variable is not found, the substitution does not occur), so its actually impossible to determine a real variable reference.

Expected Behavior

Syntax should at least support stop-parsing symbol's scope ending at a pipe, in the same manner as PowerShell actually does.

Possible tmLanguage modification:

{
	"begin": "(?<!\\w)(--%)(?!\\w)",
	"beginCaptures": {
		"1": {
			"name": "keyword.control.powershell"
		}
	},
	"end": "$|\\|",
	"patterns": [
		{
			"match": "[^\"\\x{201C}\\x{201D}]+?",
			"name": "string.unquoted.powershell"
		},
		{
			"begin": "(?:\"|\\x{201C}|\\x{201D})",
			"beginCaptures": {
				"0": {
					"name": "punctuation.definition.string.begin.powershell"
				}
			},
			"end": "(?:\"|\\x{201C}|\\x{201D})(?!\"|\\x{201C}|\\x{201D})|$",
			"endCaptures": {
				"0": {
					"name": "punctuation.definition.string.end.powershell"
				}
			},
			"name": "string.quoted.double.powershell"
		}
	],
	"comment": "This should be moved to the repository at some point."
},

I have the Unicode double-quotes included, as I determined that PowerShell treats them the same here as well as elsewhere.

I do have the intention of putting this in a PR.

Vorherrschende Sprache
PowerShell
Sterne
151
Forks
55
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus PowerShell/EditorSyntax

Alle Issues in PowerShell/EditorSyntax

Ähnliche Issues

Weitere Issues zu DevTools

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.