We are excited to announce that an update to the PowerShell Extension for Visual Studio Code is now available on the extension marketplace.
This release fixes a number of issues related to IntelliSense and enables updates to PowerShell Editor Services (the engine of the VS Code extension) for other clients, such as Emacs and Vim with LSP plug-ins.
Updates from the June releases
Some highlights of June releases:
-
Fix how we check extension mode. vscode-powershell #3992
-
Add warning about IntelliSense to PowerShell Integrated Console terminate dialog. (Thanks @JustinGrote!) vscode-powershell #3976
-
Add regression test for no defined profiles. PowerShellEditorServices #1821
-
Add Emacs regression tests for PowerShellEditorServices. PowerShellEditorServices #1820
-
Set
IsDebuggingRemoteRunspace
sooner for attach. PowerShellEditorServices #1815 -
Fix error when piping
IFilePosition
toConvertTo-ScriptExtent
. PowerShellEditorServices #1814 -
Additional IntelliSense fixes and ToolTip overhaul. PowerShellEditorServices #1809
-
Fix startup bug when zero profiles are present. PowerShellEditorServices #1807
-
Fix execution of debug prompt commands. vscode-powershell #3980
-
Re-enable stdio clients by fixing initialization sequence. PowerShellEditorServices #1695
-
Fix a lot of IntelliSense issues. PowerShellEditorServices #1799
-
Increase stack size for PowerShell 5. (Thanks @nohwnd!) vscode-powershell #3962
For the full list of changes please refer to our changelog.
IntelliSense improvements
In this release we have made a number of improvements to IntelliSense (the general term for various code editing features including: code completion, parameter info, tool-tip hovers, etc.).
Mark completion request handler as serial
Previously, if you typed Get-
very quickly, you’d get no results at all. This stops completion from being cancelled whenever a DidChangeTextDocument
notification is sent. This also lets completion cancel some other expensive requests like code lenses, which means everything is both speedier and less flaky.
Fix tasks never completing if cancelled quickly
We were exiting SynchronousTask.ExecuteSynchronously
early if the cancellation was already requested. This was not setting our state correctly, causing the caller to just fall off without warning. This made some things like finally
and using
disposals never happen, which led to a lot of erratic behavior!
Make alias discovery possible on idle
The use of Runspace.SessionStateProxy
while the pipeline thread is busy (even if you are on the pipeline thread) results in an exception. By fixing this we can also cancel GetAliasesAsync
(a slow operation) when needed, and do it while idling instead of startup.
Add “space” character to completion trigger characters
Adding the “space” character to completion triggers lets us automatically give completion results for parameter values. This also required building in some support for marking completion results as “incomplete”. This means that the client will not cache results when standard identifier characters are typed.
Mainly, this solves the scenario where you type space
, get file completion results, and then type -
. You expect to then get parameter names, but without marking “incomplete”, it will instead filter the file results.
Also fixed a scenario where you type $script:
and on typing the :
it would not update to available script scope variables.
Make completion requests cancellable
Now any completion results from custom argument completers can be cancelled if they take too long and the user keeps typing. In non-remote runspaces, we can also use it as a completion source that we can cancel by way of issuing a pipeline stop request.
What’s next for the project?
We are currently building out regression tests for the extension to cover everything we broke and subsequently fixed during the major rewrite earlier this year. We have a strong focus on quality, and want to ensure we continue to deliver a production-ready, high-quality extension to you, our users. We have made a large investment in improving the extension so we want to be able to confidently continue to iterate on this project without inadvertently impacting the performance, stability, or feature set. We’ve begun this work already, and are tracking in our GitHub repository.
Getting support and giving feedback
While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.
If you encounter any issues with the PowerShell Extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.
Sydney
PowerShell Team
0 comments