powershell / editorsyntax Goto Github PK
View Code? Open in Web Editor NEWPowerShell syntax highlighting for editors (VS Code, Atom, SublimeText, TextMate, etc.) and GitHub!
License: MIT License
PowerShell syntax highlighting for editors (VS Code, Atom, SublimeText, TextMate, etc.) and GitHub!
License: MIT License
We need to find a way to test the syntax definition to ensure that any new changes don't break the grammar. It would be ideal if this could be done with the fewest number of dependencies possible so that we could run our tests in AppVeyor when PRs are sent.
I believe @vors might have some initial idea for how we could do that.
In the following snippet
Get-AzureVMImage
| where ImageFamily -eq $imageFamily
| sort PublishedDate -Descending
| select -ExpandProperty ImageName -First 1
the aliases sort
and select
are not highlighted like the where
alias, besides representing the same type of filter/alias.
When expanding the snippet to
Get-AzureVMImage `
| Where-Object ImageFamily -eq $imageFamily `
| Sort-Object PublishedDate -Descending `
| Select-Object -ExpandProperty ImageName -First 1
Where
of Where-Object
will be highlighted as keyword, Sort-Object
won't be highlighted and Select-Object
will be highlighted as command.
Expected behavior:
Verb-xxx
) should be highlighted the same way.Note: there might be other keywords that are effected by this issue.
$PSVersionTable
:
Name Value
---- -----
PSVersion 5.1.14393.693
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.693
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Some Cmdlets are not color coded like they are supposed to in the editor pane of VSCode with default or any theme,
Cmdlets with issue - Tee-Object, Where-Object, Sort-object, could be more
A catch here could be all these cmdlets with coloring issues have an Alias same as the "Verb" in the Verb-Noun Syntax of the cmdlet, like Sort for Sort-Object
Run below one liner from vs code and see the difference in color of some cmdlets -
gcm|% name|?{$_ -like "*-*"} >TestFile.ps1;code .\TestFile.ps1
The problem I want to bring attention to is on variable syntax highlight/coloration/formatting
And I have seen this both for sublime text, atom, and VS code
basically the formatting is INCORRECT when under ""
I can understand if it was ' '
but in "" the variables are still quite functional.... and often there is text which is DIFFERENT from the variable inside like
"$variable-hello there how are you"
And we need to be able to differentiate that
$x = 100000
$EmailList = For ($i=0;$i -lt $x;$i++) {
"$(Get-RandomString -length 10)@$(Get-RandomString -length 10).com"
}
$EmailList | Set-Content -Path .\file1.txt
In the above code sample "-le" is highlighted in a different color than the rest of the string. "-Length" is a parameter of a helper function in the same script.
From @animetauren on January 30, 2017 18:0
Extension | Author | Version |
---|---|---|
python | donjayamanne | 0.5.6 |
PowerShell | ms-vscode | 0.9.0 |
Steps to Reproduce:
[parameter(Mandatory=$true, ParameterSetName="new", HelpMessage='Email Address associated with this Certificate.')][ValidatePattern('^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$')]
[String]$email,
Copied from original issue: microsoft/vscode#19589
I'd like to have a discussion where we decide on the "correct" scope names for all PowerShell language constructs. This will mean much less work when doing updates to the tmLanguage file in the future, as the scopes (as well as the color(!) of each) are checked by a Travis CI build job on the vscode repo.
.powershell
As we decide, we can fill out this table:
Language construct | Scope Name | Comments/Examples |
---|---|---|
Line comment | comment.line.number-sign | # comments |
Block comment | comment.block | <# comments #> |
Help directives | comment.documentation.embedded | Meta scope |
Help directives - keywords | keyword.operator.documentation | .SYNOPSIS |
Help directives - keyword value | constant.string.documentation | 'ParameterName' in .PARAMETER ParameterName |
#Requires statement | keywords.operator.documentation | 'Requires' in #Requires -Version 3.0 |
#Requires statement - parameter | constant.string.documentation | '-Version 3.0' in #Requires -Version 3.0 |
String - double quoted | string.quoted.double | "string" |
String - single quoted | string.quoted.single | 'string' |
String - escape characters | constant.character.escape | 't' in "onettwo" |
String - heredoc double quoted | string.quoted.double.heredoc | |
String - heredoc single quoted | string.quoted.single.heredoc | |
ScriptBlock | meta.scriptblock | { ... } |
SubExpression | meta.subexpression | $( ... ) |
Hashtable | meta.hashtable | @{ ... } |
Array | meta.array | @(1,2,3) & (1,2,3) |
Property/Member | entity.other.attribute-name | 'property' in (Invoke-Something).property & 'property' in $var.property |
Numeric Constant - real | constant.numeric.real | +.5 |
Numeric Constant - integer | constant.numeric.integer | 5 |
Numeric Constant - hexadecimal | constant.numeric.hexadecimal | 0x20 |
Type | entity.name.type | 'string' in [string] |
Type - static method | meta.method | '::MinValue' in [int]::MinValue |
Parameter decorator | entity.name.type | 'Parameter' in [Parameter(Position = 1)] |
Parameter decorator - property | entity.other.attribute-name | 'Position' in [Parameter(Position = 1)] |
Function | meta.function | Meta scope |
Function - keyword | storage.type | 'function' in function script:Invoke-Something { ... } |
Function - scope | storage.modifier.scope | 'script' in function script:Invoke-Something { ... } |
Function - name | entity.name.function | 'Invoke-Something' in function script:Invoke-Something { ... } |
Command | meta.command | Meta scope |
Command - keyword | support.function | 'Invoke-Something' in Invoke-Something -p1 'v1' |
Command - parameter | variable.parameter | '-p1' in Invoke-Something -p1 'v1' |
Reserved words | keyword.other | configuration |
Control words | keyword.control | break |
Enum - keyword | storage.type | 'enum' in enum myEnum { ... } |
Enum - name | entity.name.function | 'myEnum' in enum myEnum { ... } |
Class | meta.class | Meta scope |
Class - keyword | storage.type | 'class' in class myClass : inheritedClass { ... } |
Class - name | entity.name.function | 'myClass' in class myClass : inheritedClass { ... } |
Class - inheritance | entity.other.inherited-class | 'inheritedClass' in class myClass : inheritedClass { ... } |
Class - reserved words | keyword.other | hidden & static |
Class - control words | keyword.control.class | 'base' in : base( ... ) |
Operator - redirection | keyword.operator.redirection | 2>&1 |
Operator - comparison | keyword.operator.comparison | -gt |
Operator - bitwise | keyword.operator.bitwise | -band |
Operator - logical | keyword.operator.logical | -and |
Operator - format | keyword.operator.format | -f |
Operator - assignment | keyword.operator.assignment | += |
Operator - logical not | keyword.operator.logical-not | -not & ! |
Operator - multiplicative | keyword.operator.multiplicative | / & * |
Operator - unary plus | keyword.operator.unary-plus | + |
Operator - unary minus | keyword.operator.unary-minus | - |
Operator - additive | keyword.operator.additive | + & - |
Operator - range | keyword.operator.range | .. |
Operator - command invocation | keyword.operator.other | & |
Operator - stop parsing | keyword.operator | --% |
Switch - keyword | keyword.control | 'switch' in switch -regex ($var) { ... } |
Switch - parameter | variable.parameter | '-regex' in switch -regex ($var) { ... } |
Switch - reserved word | keyword.other | default |
Illegal | invalid.illegal | Space after backtick |
Variable - $ | keyword.other | '$' in $variable |
Variable - ${..} | keyword.other | '${' and '}' in ${variable} |
Variable - automatic | constant.language | $_ & $error |
Variable - scope | storage.modifier.scope | 'script' in $script:variable |
Variable - name | variable.other.readwrite | 'variable' in $script:variable |
I have started by filling out the scope names as I have used them in my refactored language file.
If, in the theme, there are colorization rules only for the scope constant.operator, both constant.operator and constant.operator.range will be colorized the same.
If there isn't any colorization rules for a scope, it will be colorized with the "root" color of the current scope. Meaning if the word 'test' only belong to the source scope (or have a scope name that is not defined in the current theme), it will be colorized with the default background color. If the word 'test' is found inside another scope, for instance a string, it will be colorized with the color for the string scope.
Colorization rules may differ between editors. For instance the background parameter. This is supported on Sublime Text, but not in VSCode.
A matched set of characters can be (and more often than not are) assigned multiple scopes. So for example the word variable in function MyFunction {"this is $("a $variable")"}
have the following scopes: source, string.quoted.double, meta.subexpression, string.quoted.double and lastly variable.other.readwrite. Only the last one is used for colorization.
There are five themes that are defined as default themes in Visual Studio Code:
The themes supports nesting, and:
The following scopes are defined in the plus-themes:
The following scopes are defined in the "old" default themes:
Scope names on the same line, means they are defined in the same colorization rule.
Check out Where-Object
in this screenshot / example.
function Clear-JunctionLinks {
[CmdletBinding()]
param (
)
Get-ChildItem -Path $env:TEMP -Directory | Where-Object -FilterScript { }
}
Cheers,
Trevor Sullivan
Docker Captain
Microsoft MVP: Cloud & Data Center Management
https://trevorsullivan.net
https://twitter.com/pcgeek86
From @cosmo0 in #26 (comment):
For the from/to problem: I have a method that I call like that:
Install-ConfigFiles -from "$here\tests\process" -to "$here"The
-from
is highlighted, but the-to
is white. With my color scheme (Monokai),-from
is pink and-to
is white.
Notice this is also visible on GitHub.com (as of OP).
Copied from original issue: jrsconfitto/language-powershell#24
This just started happening in the latest Code Insiders 7/27
Sample Code
if ($ModuleResults)
{
if ($ModuleResults.Installed -ne $null)
{
Write-Host "[INFO] " -ForegroundColor DarkMagenta -NoNewline
Write-Host "Installed Modules: " -NoNewLine -ForegroundColor Gray
Write-Host "$($ModuleResults.Installed -join ', ')" -ForegroundColor DarkGray
}
if ($ModuleResults.Updated -ne $null)
{
Write-Host "[INFO] " -ForegroundColor DarkMagenta -NoNewline
Write-Host "Updated Modules: " -NoNewLine -ForegroundColor Gray
Write-Host "$($ModuleResults.Updated -join ', ')" -ForegroundColor DarkGray
}
if ($ModuleResults.FailedUpdate -ne $null)
{
Write-Host "[Error] " -ForegroundColor Red -NoNewline
Write-Host "Module Update Failed: " -NoNewLine -ForegroundColor Gray
Write-Host "$($ModuleResults.FailedUpdate -join ', ')" -ForegroundColor DarkGray
}
if ($ModuleResults.FailedInstall -ne $null)
{
Write-Host "[ERROR] " -ForegroundColor Red -NoNewline
Write-Host "Module Install Failed: " -NoNewLine -ForegroundColor Gray
Write-Host "$($ModuleResults.FailedInstall -join ', ')" -ForegroundColor DarkGray
}
}
Here is how it looks by default
If I remove the dot in $ModuleResults.Installed
it clears up.
If I remove the comma inside of the quotes, you can see that it clears up the rest of the syntax outside of the double quotes, but the -join ' '
is still wrong.
Removing the double quotes still has all following syntax broken.
From @lipkau on August 22, 2017 12:49
1๎ฐProjects๎ฐ ๎ฒ๎ฒ13:09:06
I โฅ PS๎ฐcode -v
1.15.1
41abd21afdf7424c89319ee7cb0445cc6f376959
2๎ฐProjects๎ฐ ๎ฒ0:00:00.2332๎ฒ14:47:05
I โฅ PS๎ฐ$pseditor.EditorServicesVersion
Major Minor Build Revision
----- ----- ----- --------
1 4 1 0
3๎ฐProjects๎ฐ ๎ฒ0:00:00.0100๎ฒ14:47:05
I โฅ PS๎ฐcode --list-extensions --show-versions
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
4๎ฐProjects๎ฐ ๎ฒ0:00:00.3786๎ฒ14:47:06
I โฅ PS๎ฐ$PSVersionTable
Name Value
---- -----
PSVersion 5.1.15063.502
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.502
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
I have a parameter declared as: [X509Certificate] $Certificate
.
However, the numbers in the typename are not colored correctly (see screenshot)
Copied from original issue: PowerShell/vscode-powershell#1001
From @fromthewoods on February 19, 2017 5:18
I searched around and couldn't find any existing issues that address what I'm seeing, so apologies if this is already known.
I have a simple regex pattern [ValidateScript({$_ -match '^([\d\w]+\.){2,3}[\d\w]+$'})]
that vscode seems to not be able to handle and I assume it's an issue with PSEditorServices.
PowerShell ISE handles the same pattern properly.
Copied from original issue: PowerShell/PowerShellEditorServices#374
This issue was noticed in VS Code with the PowerShell plugin.
$PSVersionTable
:Name Value
---- -----
PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.9
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
The [ValidateScript({ ... })]
parameter attribute is commonly used to perform customized validation on parameter values that a caller passes into a PowerShell function. In Visual Studio Code 1.4.0
, running on Windows 10 Anniversary Update, with version 0.7.1
of the PowerShell extension, the syntax highlighting inside this parameter attribute is incorrectly handled.
The syntax highlighting should work consistently both inside and outside of a [ValidateScript({ ... })]
parameter attribute.
PowerShell/vscode-powershell#272
Cheers,
Trevor Sullivan
Docker Captain
Microsoft MVP: Cloud & Data Center Management
https://trevorsullivan.net
https://twitter.com/pcgeek86
Regex for GUID validation is breaking Syntax Highlighting
Add this to a Parameter statement to recreate issue: [ValidatePattern("^(\{){0,1}[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}(\}){0,1}$")]
VSCode 1.8.1
PowerShell extension 0.9.0
Here is a specific, reproducible example where the class
keyword is improperly colored in Visual Studio Code.
function Test-Function {
[CmdletBinding()]
param (
[string] $Class
)
}
### Notice the blue color of "Class", indicating that it is a reserved language keyword.
Test-Function -Class asdf
### Notice how the "-Name" parameter is colored differently than "-Class" above
Get-Process -Name asdf
โ ~ code --list-extensions --show-versions
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
โ ~ code -v
1.10.2
8076a19fdcab7e1fc1707952d652f0bb6c6db331
โ ~ powershell -Command '$PSversionTable'
Name Value
---- -----
PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.17
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Cheers,
Trevor Sullivan
The dollar sign $
should be included as part of the variable token because editors like VS Code use the syntax tokens to determine what text to select when the user double-clicks in the current file. Currently if the user double-clicks in a variable like $myVar
, only the myVar
portion will be selected since the $
is treated as a separate symbol.
Another one!
From @oivindoh on September 13, 2016 13:37
$SomeComputer = 'localhost'
$RemoteServicePS = @{
'VMware' = @{
'Service' = $(get-service -verbose:$false -computername $SomeComputer -displayName 'VMware Tools');
'EndpointContracts' = @('ISimService','IServiceBroker');
'Identity' = '';
};
}
$ServicesToSkip = @()
$RemoteServiceCIM = @{}; $HasServicePrincipalNames = @{}
$RemoteServicePS.GetEnumerator() | % {
$thisServiceKey = $_.Key
if ($_.Value.Service -ne $null){
$thisCIMService = $(get-ciminstance win32_service -verbose:$false -computername $_.Value.Service.MachineName -filter "name='$($_.Value.Service.ServiceName)'")
$thisCIMServiceUser = $thisCIMService.StartName
write-host $thisCIMServiceUser
# etc.
}
}
After updating language-powershell to the most recent release the following from the code above breaks code highlighting for me:
$thisCIMService = $(get-ciminstance win32_service -verbose:$false -computername $_.Value.Service.MachineName -filter "name='$($_.Value.Service.ServiceName)'")
The same also appears to be the case for the following little snippet (code hightlighting continues as before if commented out):
$thisBitVersionMatches = $FilesPresent | where {$_.FullName -match "^(?=.*$thisVersion)((?=.*$thisBitness)|(?=.*$thisSupportBit))(?=.*redist).*$"}
I also see the issue in places such as this:
foreach ($Tool in $Tools){
$ToolFromWhere.Keys | % {
if (($_ -match $Tool) -and -not ($ToolsToDownload -contains $ToolFromWhere."$($_)")){
write-verbose ('Fetching {0} from {1}' -f $_, $ToolFromWhere."$($_)")
$ToolsToDownload += $ToolFromWhere."$($_)"
[URI]$thisURI = $ToolFromWhere."$($_)"
$thisFileName = $thisURI.Segments[-1]
$thisTempFile = join-path -path $env:TEMP -childpath $thisFileName
start-bitstransfer -source $thisURI -destination $thisTempFile
Where if I comment out lines [3-6] highlighting continues.
Another example where the Where line breaks highlighting:
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse |
Get-ItemProperty -name Version,Release -EA 0 |
Where { $_.PSChildName -match '^(?!S)\p{L}'} |
Select PSChildName, Version, Release, @{
name="Product"
expression={
switch($_.Release) {
My gut feeling says it's related to PR50 since it's all directly after a foreach/where, but I'm not really sure. Is there anything I can do to provide a clearer report/exclude other potential sources of the issue?
Copied from original issue: jrsconfitto/language-powershell#53
Hi, another topic for discussion, or rather I need some feedback on how to handle syntax highlighting of parameters, more specifically of the form -Parameter
.
At the moment I have just created a very generic parameter match that highlights any occurrence of -text
as a parameter.
This is not really ideal, as stuff like $a -foobar -$b
are highlighted as a parameter. The only positive thing about this really, is that the regex is very short and easy :)
But my guess is that we should work to get parameter highlighting a bit better than this.
The tmlanguage format are kind of limiting when it comes to really complicated matching, but I think this is do-able, as long as we can clearly define a start and end for a command statement.
This is where I need your input. Is it correct to say that:
Any cases I have not thought about?
I have written some test-code that I will use to test the matching rules,again if you have any input or additions to this, please let me know. The more unique examples the better!
https://gist.github.com/gravejester/0f90a887c3765771ebc15a94120cbdeb
In PowerGUI tool, if i double clicked on $a for instance, it would highlight not only the 'a' but also the '$'.
Update your editor to do the same.
This might be related to #14
It looks like just having a dot inside of parens breaks the Syntax Highlighting in the latest Insiders Preview 7/27
Sample Code:
if ($Host.name -eq 'ConsoleHost')
{
if (! (Get-Item ENV:VSCODE_PID -ErrorAction SilentlyContinue))
{
## Set Location
Set-Location -Path Repo:
}
}
This is how it is by default.
Removing the dot makes everything OK.
Just having a dot at end of Var breaks syntax highlighting.
This one is pretty bad, it breaks a quite a lot of the PowerShell I see. May have to manually load an old syntax.
Off Topic: What syntax highlight method does Github use? they seem to have decent results with PowerShell. Always been better than tmtheme overall.
From @Satak on November 24, 2015 7:49
The whole enumeration / enum keyword feels like it's not implemented to have a support for it. Doesn't highlight the keyword or it's content and doesn't offer any snippets.
Copied from original issue: PowerShell/vscode-powershell#26
Since we're now centralizing development of the TextMate definition for PowerShell in this repo, it'd be good to find all known issues with the current state of the syntax definition and move them to this repo. It'd be great to have some help doing this (especially if someone can find a way to automate it ๐)
Here are some starting points:
@guillermooo @jugglingnutcase @vors @Jaykul @gravejester
From @SteveL-MSFT on May 17, 2017 22:58
$foo?bar = 1
"$foo?bar"
only $foo is highlighted as a variable, this causes confusion to the customer as PowerShell treats $foo?bar as the variable (which is allowed)
PSReadline highlights correctly
Copied from original issue: PowerShell/vscode-powershell#759
Once we've got the final issues worked out of the refactored syntax definition we should send a PR to GitHub's linguist project so that they can benefit from the improvements.
The latest 0.12.1 version of the VSCode PowerShell extension seems to have introduced a bug where the Where-Object
cmdlet is not properly syntax highlighted.
PS C:\Users\tsulli> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.693
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.693
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
PS C:\Users\tsulli> code --list-extensions --show-versions
[email protected]
PS C:\Users\tsulli> code -v
1.10.2
8076a19fdcab7e1fc1707952d652f0bb6c6db331
Cheers,
Trevor Sullivan
A standard CmdLet like Select-Object is colored yellow, as this represents a function I assume this is normal. However, when using splatting, the properties are also indicated in yellow. This way it's hard to see the difference between a function and a splatting property.
You can see that the word ErrorAction is yellow, the same as it is for a function. This seems to be incorrect. Also the coloring of the words -Property , ProcessName and @SelectParams isn't done. And the word $true is just a variable, which should have the same color as any other variable, like $SelectParams for example.
Test code for convenience:
$SelectParams = @{
Property = 'ProcessName'
Verbose = $true
}
$SelectParams.ErrorAction = 'Stop'
Get-Process | Select-Object -Property ProcessName
Get-Process | Select-Object @SelectParams
Hello,
Really loving the syntax highlighting in combo with VSCode. I've been looking for a way to defeat my ultimate Powershell enemy:
if\s*\(.*=.*\)
Any valid uses for this? Would a warning be warranted? Any way I can extend ISE or VSCode to do this?
Thanks in advance for consideration.
Moving this issue over from PowerShell/vscode-powershell#238 for @stej. @gravejester might have fixed this already in his new definition so we'll have to verify it once we get the test system running.
I have this code:
Get-SomeXml |
Select-Object -ExpandProperty Node |
% { if ($_.'#text') { $_.'#text'.Trim() -split ',\s*' }
else { @() }
}
The syntax highlighter is confused from the ending apostrophe behind the #text
property.
The problem is probably caused by the hash sigh #
, because once I remove it, it is ok.
Workaround
$textProp = '#text' # just workaround because of syntax highlighter
Get-SomeXml |
Select-Object -ExpandProperty Node |
% { if ($_.$textProp) { $_.$textProp.Trim() -split ',\s*' }
else { @() }
}
The new syntax is awesome for parameters and parameter attributes, but I did notice one issue with the HelpMessage attribute. It was getting colored a different color than the others.
I'm on my phone atm, but I'll try to get an image shortly.
I'd like a discussion to decide whether +|- before a digit should be scoped as a part of the number literal or as a unary operator.
In IE it's scoped (and highlighted) as part of the number literal, but according to the PowerShell Language Specification they are in fact considered unary operators.
My initial though were to follow the specifications, but what are your thoughts?
Examples:
12 + 7
Here the + is clearly an operator.
+7
The question is whether it should be here as well, considering that this is also allowed:
-$true
and +"0xabc"
I have a PowerShell code file with two #requires
statements. The code works properly, but the syntax highlighting is improper.
Specifically:
-module
on the second #requires
statement should be consistently colored. Right now, the dash is colored differently from the parameter name.ServerManager
argument should be colored consistently with parameter values, according to the current theme (this might be debatable)Cheers,
Trevor Sullivan
Microsoft MVP: Cloud & Data Center Management
https://trevorsullivan.net
https://twitter.com/pcgeek86
Hi:
I am working with PowerShell modules (.psm1 files). As per best practice I am creating a manifest file (.psd1) for each module, using the built-in New-ModuleManifest cmdlet. I'm just generating relatively generic manifest files (no options fed into the cmdlet to customize), and then editing manually. Immediately after creating the manifest file, I display with "type MyModule.psd1" and see results like this:
# Module manifest for Module MyModule' # # Generated By: blah
Atom lists the file type at the bottom as "UTF-8" which should be fine, but if I delete characters, it actually takes 2 keystrokes to delete each. If I save the resulting .psd1 file, then use the standard Import-Module cmdlet, PowerShell complains the manifest is not in a correct format. If I then display the file through the command line again, I see:
# M o d u l e m a n i f e s t f o r M o d u l e M y M o d u l e ' # # G e n e r a t e d B y : b l a h
It appears Atom thinks .psd1 files are UTF-16 and then saving as such, which PowerShell does not work well with.
I can provide examples if required. Is there a workaround for this?
The following line is incorrectly colored:
& $oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,b$isoPath\boot\etfsboot.com#pEF,e,b$isoPath\efi\microsoft\boot\efisys.bin $isoPath $outputPath
VS Code treats the first "#" as the start of a comment, whereas it really is just a part of the command arguments passed to the call operator.
See also: https://github.com/PowerShell/vscode-powershell/issues/974
From @Roadkill4545 on January 30, 2017 15:13
$PSVersionTable
:Name Value
PSVersion 5.0.10586.117
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.117
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Evaluate $PSVersionTable in PowerShell and paste the output here
This should be an easy one (I hope!). I am experiencing a problem with syntax highlighting and color. The syntax coloring becomes off when I use the following line of code in my script:
[ValidatePattern("^([0-9A-Ha-h][0-9A-Ha-h](:|-)?){7}[0-9A-Ha-h][0-9A-Ha-h]`$")][String[]] $Wwpn,
Specifically, it takes issue with the backtick-dollarsign combination. If I remove the dollar sign, the coloring in all of the code below this line works again. Note the code itself works correctly, its simply the syntax color highlighting in VS Code that breaks. Here is an example of how to reproduce:
function Test-Function1()
{
param
(
[ValidatePattern("^([0-9A-Ha-h][0-9A-Ha-h](:|-)?){7}`$")][String[]] $Wwpn,
[string] $p1,
[string] $p2
)
Write-Host ("All of the text colors are correct, but they will be broken below.")
}
function Test-Function2()
{
param
(
[ValidatePattern("^([0-9A-Ha-h][0-9A-Ha-h](:|-)?){7}[0-9A-Ha-h][0-9A-Ha-h]`$")][String[]] $Wwpn,
[string] $p1,
[string] $p2
)
Write-Host ("The [0-9A-Ha-h][0-9A-Ha-h] sequence in function1 above breaks the code coloring. Not sure why...")
}
# Observe the oddness in code coloring. However the functions above indeed do work!
Follow the instructions in the README
about capturing and sending logs.
Copied from original issue: PowerShell/vscode-powershell#472
There are a number of scopes that we use in the PowerShell syntax highlighting definitions that are not currently colorized in the default themes in Visual Studio Code.
For instance:
Should we try to get some colors for these into the default themes? Or should we create our own PowerShell optimized versions of the default themes? I'm mainly thinking about the default light+ and dark+ themes.
I'd rather not use the "wrong" scope names just to get colors. This will only mess things up when you change to other themes.
From @pcgeek86 on October 28, 2016 5:2
$PSVersionTable
:PS C:\Users\TrevorSullivan> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.206
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.206
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
When I utilize a .NET class that exists within a .NET namespace, whose name contains a number character, the syntax highlighter incorrectly colors the numeric characters in the fully qualified type name.
Copied from original issue: PowerShell/vscode-powershell#328
Win 7 Prof 64Bit
1.5.3
0.7.2
$PSVersionTable
:Name Value
---- -----
PSVersion 5.0.10586.117
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.117
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
I noticed a syntax highlight issue while using regex in [ValidatePattern()]
.
There's syntax highlighting to indicate commands which makes things like something.bat
and ipconfig.exe
the same color as PowerShell cmdlets like import-module
. The highlighting for .bat and .exe files doesn't properly detect when .bat or .exe is part of a longer word.
ipconfig.exe
Import-Module AzureRM.Backup
Import-Module AzureRm.Batch
Import-Module AzureRm.Exefake
Import-Module AzureRM.Cdn
Using Monokai Dimmed theme for emphasis.
Lines 4 and 5 have incorrect syntax highlighting.
[email protected]
[email protected]
[email protected]
[email protected]
code -v
1.11.2
6eaebe3b9c70406d67c97779468c324a7a95db0e
$PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.1066
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.1066
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
I ran into this issue using the PowerShell extension for VS Code and was referred to this project.
When adding comments on the same line as a function where the opening brace is on the next line, the comment doesn't get formatted correctly.
I'm using the Dark+ (default dark) theme and comments are green, however, when entered into this line they appear as grey.
As an example:
Function New-Function { #comment here
}
formats fine with a green comment, however,
Function New-Function #comment here
{
}
doesn't format correctly and the comment remains grey.
Working on some API call wrapper functions for the first time in Visual Studio Code and I noticed that question marks immediately following a variable are not highlighted as part of the variable. In ISE, it's easy to catch because the question mark will highlight orange and needs to be escaped to be not be considered part of the variable. In VSCode, there's no marker.
Example:
"https://www.googleapis.com/drive/v3/teamdrives/$TeamDriveID?fields=capabilities%2Cid%2Ckind%2Cname"
In ISE, the ?fields
after $TeamDriveID
will be included in the variable, renaming the variable to $TeamDriveID?fields
and causing it to fail. In VS Code, there's no indicator via Syntax Highlighting that that extra bit is being included.
Would it be possible to have the PowerShell integrated terminal pull the theme colors for code from the vscode theme? This way whatever theme is selected for vscode the same code color would be replicated in side the integrated terminal?
Is it possible to switch YAML for editing language syntax? This idea came after visiting Microsoft/TypeScript-TmLanguage.
The current list of keywords includes a few new keywords which are supposedly there to allow customization of help based on user roles or functionality.
These words aren't use in the built-in cmdlets, but they are documented in both Comment-Based Help Keywords and about_comment_based_help -- so they should be included in the syntax.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.