aramk / crayon-syntax-highlighter

Syntax Highlighter supporting multiple languages, themes, fonts, highlighting from a URL, local file or post text.
https://wordpress.org/plugins/crayon-syntax-highlighter/
GNU General Public License v3.0
1.1k stars 249 forks source link

PowerShell Improvements #177

Open aramk opened 10 years ago

aramk commented 10 years ago

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.

ITFiend commented 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)

  1. Backtick (`) issues (may be resolved now by #178). Will wait to explore more though, as the next number of this post is only partially fixed. (Image line 49 appears fixed)
  2. Crayon now has partial understanding of Here-Strings. @" "@ are now supported due to #178, however @' '@ are still an issue. (Image Lines 12-17 fixed, but lines 19-24 are not)
  3. Backslash () issues (appear to be resolved by #178 as lines 44 and 51 from my images now behave properly). *Appears github cannot render a \ when placed inside (), but its definitely there when editing this message.
  4. I have no idea what is causing the color oddity on line 60. It should be identical to line 67. Earlier while building this faux-script to show problems it was the other way around with the issue on line 67 instead, but something else I changed resulted in the color bug flipping position.

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.

ps-powershellise

ps-crayonrendering

ITFiend commented 10 years ago

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.

ITFiend commented 10 years ago

Bug Updates:

  1. I repeated the line with the color issue multiple times in a more isolated setting. This may help locate the cause of the problem. In the second image, the issue is on line 12.

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.

ps-crayonrendering 5-1

ps-crayonrendering 5-2

New bug noticed:

  1. On line 49 of the original images I posted, for some reason color coding is lost when it gets to ".DirectoryContext".
mixProtocol commented 10 years ago

I didn't realize that here-strings could be single-quoted... I've created another PR (#179)

ITFiend commented 10 years ago

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.

ps-crayonbackticks

mixProtocol commented 10 years ago

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.

ITFiend commented 10 years ago

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.

ITFiend commented 10 years ago

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.

ITFiend commented 10 years ago

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.

crayon-powershellisetheme

ITFiend commented 10 years ago

The graphical bugs I may not be able to fix at my current lack of PHP skill appear to be...

  1. Variables within double-quote here strings are not rendering their color.
  2. [System.Math] and calls like it appear to use the same theme colors as a non-commented switch value.
  3. .DirectoryContext not recognized as part of the system object being called on.

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.