Open aramk opened 10 years ago
Aramk, after receiving your e-mail I wanted to update this. I've moved to the Vs2012 color scheme as my default since it’s the most similar to the PowerShell ISE. PowerShell is set as the language default.
The bugs I've encountered which you'll see in the pictures. (images updated post #178 changes)
Visual Feature Requests: The largest problem I see with Crayon rendering PowerShell is that it doesn't track & render PowerShell $Variables. If it were made to render those properly, it would need knowledge of all the default variables displayed through the command "get-variable" and default legacy system $env: variables displayed with the command "(ls env:).Name".
Everything else in the images is just a comparison of what I hope is a minor feature request for Crayon getting a PowerShell ISE v4 theme added.
I've updated my original post and images. Now reflects changes from #178. Also clarified most visual issues as a feature request as they are not bugs and I presume should be moved to a different ticket once the real bugs are resolved.
Bug Updates:
The values on line 5 and 11 are also consistently not rendered like other text, but I'm guessing that this may be on purpose like the backslashes on lines 3 and 9 for the Vs2012 theme.
New bug noticed:
I didn't realize that here-strings could be single-quoted... I've created another PR (#179)
mixProtocol, I am able to break the backtick support slightly. See attached image.
Line 2 is breaks due to the way the quotes end.
Line 10 doesn't recognize the final single quote as an ending because of the backtick.
Yeah, I'd thought about the double-backtick (``) causing a problem (as you show in line 2). I think I can fix that with a nested negative lookbehind which should push the problem to the triple- or quadruple-backtick (which is likely a true corner-case). I don't think there's a simple regex test for "if not proceeded by an odd number of backticks".
As for line 10, I forgot that you can't use the backtick as an escape char in single-quoted strings. I'll correct that. Can backticks be used as an escape char in single-quoted Here-Strings? If not, can fix that too.
I have pending pull request (#179) -- I'll see how that gets merged first before proceeding.
Actually... I don't believe backticks can ever be used as an escape character within both single and double quote Here-String. The whole point of Here-Strings is to try and get rid of the need for backticks and allow more natural text to exist. I believe when backticks are used in Here-Strings, they will always be used like every other normal character.
Here-String openings and endings are also very special. When a Here-String opens, text may exist before the opening, but no text may exist on the same line after the @" or @' except white-space. When a Here-String closes, no text may exist on the same line before the "@ or '@. Not even white-space is allowed to exist before the closing of a Here-String. After a nest level of a Here-String closes, you can put just about any text in after the closing.
So for Crayon, backticks should probably never invoke any visual change if they are within Here-Strings, and they should just be treated as normal text characters.
Just to confirm, yes, backticks never function as an escape character in any type of Here-String.
Everything else in Here-Strings however should operate as they do in their equivalent double and single quote strings. Single quotes will not render variables and output is 100% as-written.
The only other thing to be aware about here-strings if you ever test them, is impossible to manually input them into the PowerShell CLI and have them work correctly. They only work through function, script, or in PowerShell ISE via any execution method.
I've created a baseline PowerShell theme #181 . Will continue to try and fix a few of the remaining colorization issues within it. Not sure yet on how to create references like mixProtocol did a few days ago.
This resolves most of the Visual Feature Requests I was making, though there are still a few buggy looking pieces needing to be fixed.
Attached is an image of the faux script with the new theme.
The graphical bugs I may not be able to fix at my current lack of PHP skill appear to be...
Some of the other shading issues I think I'll be able to fix. Anyway, it’s looking proper enough now that I'll start feeding it some real scripts again to work out what I can.
From an email:
It doesn’t render the first @ as part of a here string. Strings and here strings are green when they should be a redish brown: @" This is A hear string@ "@
Comments # and <# #> are orange rather than green.
Bits of commands after a switch are black and randomly blue when they should be purple without quotes, and a reddish brown when in quotes, except variables which they should always be orange.
Variables are blue when they should be orange.
Commands names are purple when they should be blue.
Command switches are blue when they should be more blackish.
Calls within [] are black instead of cyan.
Numbers appear to always render red.