Number sign in path breaks highlighting

[TylerLeonhardt]

When a number sign is part of a path, the highlighting breaks for everything on that line after the number sign.

Here's how it looks with a number sign:

And If I delete the number sign, it works again.

moved from: PowerShell/vscode-powershell#150

[omniomi]

So... That path is legal, I can't see this coming up very often though. I'd say escape as a workaround and we'll put this on the list with low priority.

[TylerLeonhardt]

@omniomi is the squiggly from Script Analyzer? Or from something relating to editor syntax?

[omniomi]

@tylerl0706 it's from script analyzer.

[msftrncs]

A solution: "commentLine", "begin" match:

"(?<![`\\\p{L}0-9_*\[\]/.?=:~!$^%+-])(#)#*"

(this captures the comment mark in group 1, a change made for a different issue)

basically, any valid filename character.

I am documenting the solutions I find for each issue so I do not lose track of them. This solution may contain other solutions to other issues, and it may not be fully tested yet. I implement them on my systems so as to improve my experience with VS Code.

[TylerLeonhardt]

@msftrncs you could also submit PRs to keep track of solutions 😉

[omniomi]

@msftrncs there's an unescaped / in your regex. Beyond that there's a couple "even though you shouldn't you can" PowerShell cases this doesn't cover (one of the hardest parts of dealing with PowerShell via RegEx.) For example, $Var#Hello is valid and is half variable half comment and ${Var #Hello} is also valid however it's all variable. You can also do $i = 0#Set Integer, etc.

Welcome to my hell ;) You cannot always assume there will be a space because PowerShell doesn't care and some people are heathens (I kid of course, but some people absolutely add comments without spaces.)

[msftrncs]

@omniomi, do forward slashes (/) require escaping in regex?

I figure there was something I was missing … I know it cannot rely on spaces, but forgot that the command processor has state (or mode) logic available to it and could still switch its processing at any boundary it chooses, unlike tmLanguage. Regex lookbehind will not be enough for that.

So how many other places might I have missed? A possible solution to correct my 'possible' :) solution is to add regex for comment line to the end of every single variable and member. It requires renumbering all the captures, as capture 0 can no longer be used (where it was).

BTW, I have already got the ${Var #Hello} solution down. It actually works for ${script:this``{name``}is"valid"} as well as $var?iable. I'll mention this on your rewrite variable issue, as it wraps several variable patterns together (from 4 to 2 in each variable section)

The only other item I found was some#thing.exe

I'd love to do PR's, but I am only working on my local copy VSCode's JSON language file. I've got to believe you guys do not actually edit that tmLanguage file with a text editor, but I couldn't find any tools quickly.

[omniomi]

do forward slashes (/) require escaping in regex?

Sorry, in PCRE they do... which is where my head was when I looked at it. In the tmLanguage file they do not.

I've got to believe you guys do not actually edit that tmLanguage file with a text editor, but I couldn't find any tools quickly.

Haha, I actually do edit the xml-plist file directly using VS Code then build it to json to test it. I was planning to write a script that could go the other direction so one could work in json and then build to xml-plist but It's surprisingly difficult and I haven't finished it.

[msftrncs]

:) I was thinking about scripting such a conversion myself. I haven't gotten far enough to find out how difficult it is yet!

[msftrncs]

@omniomi,

See if this can be of any help regarding tmLanguage.JSON & tmLanguage
https://github.com/msftrncs/PwshJSONtoPList