vscode-powershell: Semantic Syntax is incorrectly highlighting arguments as commands
Any bare (unquoted) string argument that has a - in it is being highlighted as a command:

About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 20 (4 by maintainers)
So I think we need to take this in two stages.
The first stage is parity: being as close to PSReadLine as possible. This will allow both the console and editing experience to be on the same playing field. (this was actually the original goal of doing this work from the beginning)
The second stage is improving: Once both experiences are roughly aligned, then we can go back and make the changes in both to support the language better.
@rjmholt I think what they’re getting at is that the current regex based highlighter treats the name in a function definition like a command (which doesn’t have the flag).
Personally I’d rather have the name in a function definition be parsed as a bare word than the current situation (that’s how both the ISE and PSRL work currently). But a fix for both might be just keeping track of if the previous token kind was
Function. Then also useTokenFlags.CommandName.I don’t think there’s that much backward compatibility to worry about. It’s already drastically changing most of the highlighting… and not just breaking changes like using statements with paths, escaped characters,
#requires, etc.And PSReadline is wrong about that too. Both your
hereand'there'are strings. Why would you want to make them seem different? No offense intended. I mean, I did most of the regex parser, I’m not trying to blame anyone. I’m just pointing out that it’s literally a string (and now, we know that) but it’s not highlighted as one just because … we never bothered to get it right.Yeah it’s not about how PowerShell uses it, it’s about how it’s highlighted. Categorising it as a string for highlighting purposes will make
'input'andinputthe same colour, whereas in PSReadLine for example, they are not at all (herevs'there'):Please keep your tone civil. We can be more constructive without rhetoric like this.
Nah, I’m saying people will be annoyed if it’s highlighted like every other string literal, because that’s what they’re used to.
Yeah, no one here thinks it isn’t a string. Doesn’t change the fact that folks expect it to be highlighted differently 🤷
Yes, I noticed that. But in @Jaykul’s original issue description he seems to be referring to the
CommandAstsituation rather than theFunctionDefinitionAstsituation.The
FunctionDefinitionAstscenario is easy to address: we look back a token and see if it’s thefunctionkeyword. Given that the grammar defines the full nature of the context, rather than just the tokens, we can’t do a simple token search for all tokens, but I believe we can in this case.A more sophisticated approach is to track our position in both the AST and the token array simulataneously and for each token look into where we are in the AST to determine the token semantics.
I’ve written an example where we track through tokens as we move through an AST here.
Or the converse, where we find the AST element corresponding to our token: