reloading plugin PowerShell.setup
Traceback (most recent call last):
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 73, in reload_plugin
    m = importlib.import_module(modulename)
  File "X/importlib/__init__.py", line 88, in import_module
  File "<frozen importlib._bootstrap>", line 1577, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1558, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1525, in _find_and_load_unlocked
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 671, in load_module
    exec(compile(source, source_path, 'exec'), mod.__dict__)
  File "setup in C:\Users\...\AppData\Roaming\Sublime Text 3\Installed Packages\PowerShell.sublime-package", line 1
    # encoding: utf-8
      ^

System: Windows 7 - 64-bit; Sublime Text 3

And on OSX:

reloading plugin PowerShell.setup
Traceback (most recent call last):
  File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 73, in reload_plugin
    m = importlib.import_module(modulename)
  File "X/importlib/__init__.py", line 88, in import_module
  File "<frozen importlib._bootstrap>", line 1577, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1558, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1525, in _find_and_load_unlocked
  File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 671, in load_module
    exec(compile(source, source_path, 'exec'), mod.__dict__)
  File "setup in /Users/.../Library/Application Support/Sublime Text 3/Installed Packages/PowerShell.sublime-package", line 1
    # encoding: utf-8
      ^
SyntaxError: invalid character in identifier
plugins loaded

I've noticed that the build-in command aliases (like select, where, gi etc.) are not highlighted. It will be nice to have these highlighted (possibly in different color from cmdlets).

Basically, we need to throw away the build infrastructure in place right now and use roughly the same as Vintageous or Dart (Sublime Text package) are using.

The Export-Csv parameter "-NoTypeInformation" has only the first 3 characters colored. This is probably incorrectly identifying it as "-not".

When sublime text is trying to load the plugin it gives the following error:

Traceback (most recent call last):
File "./sublime_plugin.py", line 62, in reload_plugin
File "./setup.py", line 11, in
from distutils import log, dir_util, dep_util, file_util, archive_util
ImportError: No module named distutils

I've tried to include distutils folder from the default python install on my system to sublime text's python26.zip with no success.

Sublime Text 2.0.1 on Slackware 14.0 (kernel 3.2.29)

Update: It worked after I removed setup.py file.

Error in sublime console, I am running Mac Yosemite Beta 2.

reloading plugin PowerShell.setup
Traceback (most recent call last):
  File "/Applications/Sublime Text 3.app/Contents/MacOS/sublime_plugin.py", line 73, in reload_plugin
    m = importlib.import_module(modulename)
  File "./importlib/__init__.py", line 90, in import_module
  File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
  File "/Applications/Sublime Text 3.app/Contents/MacOS/sublime_plugin.py", line 671, in load_module
    exec(compile(source, source_path, 'exec'), mod.__dict__)
  File "setup in /Users/Randy/Library/Application Support/Sublime Text 3/Installed Packages/PowerShell.sublime-package", line 1
    # encoding: utf-8
      ^
SyntaxError: invalid character in identifier

It seems that it has something to do with the characters of the first line.

May be a bug in regexp on line 220 in PowershellSyntax.tmLanguage?

Could you please register the package in package control's ST3 registry so that we can install this through it?
I believe wbond posted instructions in the package control website.

After installing the package according to the docs, I get this error in SublimeText startup:

reloading plugin PowerShell.setup
Traceback (most recent call last):
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 73, in reload_plugin
    m = importlib.import_module(modulename)
  File "./importlib/__init__.py", line 90, in import_module
  File "<frozen importlib._bootstrap>", line 1584, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1565, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1532, in _find_and_load_unlocked
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 671, in load_module
    exec(compile(source, source_path, 'exec'), mod.__dict__)
  File "setup in C:\Users\jaraco\AppData\Roaming\Sublime Text 3\Installed Packages\PowerShell.sublime-package", line 51
    raise DistutilsExecError, \
                            ^
SyntaxError: invalid syntax

Оne-line comment spreads to the rest of the text.
http://bit.ly/1zBITIF

Possible cause: linguist handles include #commentEmbeddedDocs differently then ST.

I often name parameter $input and troubleshoot same problem again and again: $input is a reserved variable.

I think you need to change your regex so that it's not as greedy.

This blows up the formatting

function subl { &"${Env:ProgramFiles}\Sublime Text 2\sublime_text.exe" $args }

If I put the ending } on a newline, we're all good

function subl { &"${Env:ProgramFiles}\Sublime Text 2\sublime_text.exe" $args 
}

Discussion started in #78

I'll try to start work on a prototype server to run PS code from a custom runspace. The server will most probably be written in F# and communicate with ST via pipes.

Tested on tag 2.0.0

Take this sample

$msBuildDir = if ((-not $IsSystem32Bit)) { "${env:ProgramW6432}" } else { "${env:ProgramFiles}" }
$msBuildDir += '\MSBuild\Microsoft\VisualStudio\v10.0'

The opening " is properly colored, but then by the time the second " is reached, the formatting is wrong. The rules seem to be treating the whole rest of the line after the first " as a variable (the line is not colored the same as a string).

For the following line, the += symbol should be in the same color as the = of the previous line, but instead, it's colored as if it were a string.

In a longer sample, all the formatting in the file is thrown off after the first line.

Note that this code is performing interpolation unnecessarily and could be rewritten as

$msBuildDir = if ((-not $IsSystem32Bit)) { $env:ProgramW6432 } else { $env:ProgramFiles }
$msBuildDir += '\MSBuild\Microsoft\VisualStudio\v10.0'

But it's trivial to think of examples where you might want to string interpolate on Provider variables (those with : that require interpolation as ${foo:bar}

mof files describes schema of PowerShell DesiredStateConfiguration resources and instances of configurations. It's a pretty hot feature of v4 / v5.

I've tried to list powershell functions in Symbol List (Ctrl-R) by adding additional preferences file. It didn't work, although this approach worked fine for my custom language syntax. How should it be done properly in this case?

I have added Packages\PowerShell\Support\PowershellSymbols.tmPreferences with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>name</key>
    <string>Functions</string>
    <key>scope</key>
    <string>source.powershell</string>
    <key>settings</key>
    <dict>
      <key>showInSymbolList</key>
      <integer>1</integer>
      <key>symbolTransformation</key>
      <string>
         s/\s*Function (\S*)/Func $1/g;
      </string>
    </dict>
    <key>uuid</key>
    <string>06532840-4879-11df-9879-0800200c9a66</string>
</dict>
</plist>

A very specific $() sequence causes the end of a string to not get recognized, which breaks syntax highlighting for all following code. This really needs to be explained with pictures. I have narrowed down the use case to this:

    foo "$(x).exe"

    function blah() {
        $blah = 'blah' # comment
    }

Which looks like this:

Whereas it really ought to look like this:

The correct syntax highlighting can be restored any number of ways:

• Commenting out the top line with #
• Changing "exe" to anything else (as I've done in the second screen shot). For example, 'xexe' or 'e'.
• Putting an extra double quote at the end of the line, or on a following line
• Messing around with the location of the parens.

Some kind of pathological case for whatever rx's are operating underneath has been hit.

I've been able to work around the issue by using an -f formatter rather than string interpolation.

This is with v2015.01.27.08.27.14.

First of all, I want to share some highlights of the recent release 2.1.0

• New unit test framework allows describe fundamental rules about syntax scopes. Now ST scopes can be compared to tokens, produced by PS parser (used for powershell_ise and PSReadLine highlighting). Credits to @guillermooo for introducing unit tests.
• Tons of bugfixes for syntax. Credits to @bcrotty for his contribution. Credits to @Jaykul for his contribution for previous release 2.0.0 and support for PS v3.
• Github syntax highlight library will use our work for all github powershell code! I don't have information when it will happen, but eventually we will impact experience for all open source powershell developers. I'm quite excited about it.

For next release, there are few areas where we can improve.

• Better test automation to reduce risk of regressions. Currently, unit tests have quite few ignored errors.
• New language features, like #42 and #43
• Clean up old bugs (older then 2015): fix/close.
• Make goto symbol feature usable #27

I encourage you to share opinions, what you want to see in the next release.

Then, I will create a milestone 2.2.0 with general description of milestone's goals and assign actionable items to it.

Not handling @' '@ here documents hide/show properly, such as the following example:

if($true) {
$script = @'
/bin/true
'@
if($false) {
write-host "Never happened"
}
}

This example gives the option to hide everything from '@ to the last }, which is not correct.

Second is powershell_ise

Compare highlighting in 35f4d4c and powershell_ise:

There seems to be a problem with syntax highlighting for Powershell Here strings.

@”

Sample Text

“@  | Sample-Command  

Seems to format correctly.

However,

@’

Sample Text

‘@ | Sample-Command

Does not.

Compare highlighting in 35f4d4c and powershell_ise:

Only one of the snippets includes a description tag, so most are using the file name for the name of the snippet, but even the file names are not all consistent. Also, the expanded text is not always formatted properly, such as the Set-PSDebug snippet, which should be capitalized as shown.

Provided that we are ok with giving up the master branch for development (i. e., its sole purpose is to mark stable releases):

Before each release, we would create a temp-release branch forking dev, delete the development files there, and merge temp-release with master. (Just an example, the process may be further streamlined.)

I work with Powershell for a long time now and I've never seen somebody to write operators in title case (e.g. -And, -Eq etc). I think they should be highlighted only if they are all small case. This will also prevent bugs like highlighting part of cmdlets' parameters, like for example the -NoTypeInformation param of Export-CSV cmdlet.

Best regards,
Mad Doctor

We should add a snippet for documentation. https://technet.microsoft.com/en-us/magazine/ff458353.aspx is the closest I found to a published standard.

Their example is:

<#

.SYNOPSIS

Retrieves service pack and operating system information from one or more remote computers.



.DESCRIPTION

The Get-Inventory function uses Windows Management Instrumentation (WMI) toretrieve service pack version, operating system build number, and BIOS serial number from one or more remote computers. 

Computer names or IP addresses are expected as pipeline input, or may bepassed to the –computerName parameter. 

Each computer is contacted sequentially, not in parallel.



.PARAMETER computerNameAccepts 

a single computer name or an array of computer names. You mayalso provide IP addresses.



.PARAMETER path

The path and file name of a text file. Any computers that cannot be reached will be logged to this file. 

This is an optional parameter; if it is notincluded, no log file will be generated.



.EXAMPLE

Read computer names from Active Directory and retrieve their inventory information.

Get-ADComputer –filter * | Select{Name="computerName";Expression={$_.Name}} | Get-Inventory.



.EXAMPLE 

Read computer names from a file (one name per line) and retrieve their inventory information

Get-Content c:\names.txt | Get-Inventory.



.NOTES

You need to run this function as a member of the Domain Admins group; doing so is the only way to ensure you have permission to query WMI from the remote computers.

#>

There is an extra dash in regexp on line 148 in PowershellSyntax.JSON-tmLanguage:

"match": "-(?i:f|band|bor|-bnot)\b",

Should be

"match": "-(?i:f|band|bor|bnot)\b",

Use PowerShell instead if possible.

For some reason I can not Import-Module AWSPowerShell, I must
Import-Module -Name "C:\Program Files (x86)\AWS Tools\PowerShell\AWSPowerShell\AWSPowerShell.dll"

I've also tried to remove the -noprofile from the build script and that didn't work either. Is this known, or would you happen to know why? When I run the same script from my local powershell, using -noprofile -file C:\foo.ps1 the script works as expected. When running the script via the CTRL+B from within sublime I get the following output:

Import-Module : The specified module 'AWSPowerShell' was not loaded because no
valid module file was found in any module directory.

Edit: I tried removing the -noprofile again and think that resolved it. I'm not totally sure what's going on but it appeared that my $env:psmodulepath was wrong.. again I think this was something on my end and this can likely be closed

The following scopes all do not allow any word characters before them, which does not allow for the above legal syntax. The current syntax does correctly catch that the last example is wrong.

keyword.operator.comparison.powershell
keyword.operator.comparison.powershell
keyword.operator.unary.powershell
keyword.operator.logical.powershell
keyword.operator.bitwise.powershell

The three valid cases I've found are:

1. Preceded by a number
2. Preceded by a variable (possibly with properties/methods)
3. Preceded by another operator or an operator with a value (e.g. 1-or1-gt2)

If you remove the check for preceding word characters, the syntax correctly identifies all but the last example, which it incorrectly allows.

For a while I thought about enforcing writing new UTs for new changes and gradually increasing coverage for existing code as a quality strategy for syntax.

Here are downsides that I see now:

1. This plan needs a lot of effort.
2. New tests are not easy to write, which discourage contribution.

I decided to implement a different approach:

1. Test cases will exist in form of simple test-file.ps1 file.
2. Test framework will use PowerShell parser/tokenizer to produce a canonical highlighting (same as powershell_ise or PSReadLine use).
3. Test framework will apply set of rules and heuristic to compare two highlighting and report suspicious places.

The current logical operator syntax catches -le in -less or anything where letters follow a logical operator. I fixed this in the commit https://github.com/bcrotty/PowerShell/commit/2c27801ea403320c3ba0dc6de95f095f9b74c5de.

For instance, this fails to parse properly.

&'hg' pull `-u `""$FormsRepo"`" `""$TempFormsPath"`"

The matching quotes should be found around "$FormsRepo" but instead are found at the beginning like ""$FormsRepo.

The current regex in the tmLanguage file

<key>begin</key>
<string>(?&lt;!")"</string>

I believe this regex needs to be rewritten so that it can match

""

BUT only if it appears as

`""

This ends up being a bit tricky with the Sublime Text regex parser because zero-width lookbehinds have to be fixed length strings (unlike lookaheads which can themselves be regular expressions). I messed around a little and couldn't find a great solution (even using conditionals)