Adding Predictive IntelliSense to PowerShell VSCode Extension

[theJasonHelmick]

Adding Predictive IntelliSense to PowerShell VSCode Extension

Summary of new feature

Predictive IntelliSense is an addition to the concept of tab completion that assists the user in
successfully completing commands. This enables new and experienced users of PowerShell to discover,
edit, and execute full commands based on matching predictions from the users history and additional
domain specific plugins such as
Az.Tools.Predictor.

PowerShell users would benefit from predictions in VSCode Terminal (PowerShell Integrated Console)
and Editor:

• PowerShell users with previous cmdlet experience receive suggestions from history and additional
  plugins, accelerating the time to command completion. Historical predictions come from the users
  PSReadLine history of completed commands, allowing them to quickly accept the prediction.

• PowerShell users without previous cmdlet experience receive guided suggestions from plugin
  predictors like Az.Tools.Predictor to help successfully complete the command. These plugins may
  provide a range of guided assistance in the form of complete commands or suggesting parameters and
  arguments.

Terminal

Terminal (PowerShell Integrated Console), should have the same features as PowerShell (shell) with
predictions as described in this
blog.

This includes InLineView and ListView for predictions, switchable with F2 key.

• Example of InLineView in PowerShell Integrated Console:

• Example of ListView in PowerShell Integrated Console:

Editor

Displaying predictions in the editor could be similar to IntelliCode for Visual Studio described
here.

When the user begins to type a cmdlet, a prediction using InLineView appears above other cmdlet
names. A star indicates that the suggestion comes from a predictor, followed by the InLineView
prediction, followed by the prediction source.

After the cmdlet name, when the user types dash (-) to begin a parameter, the first suggestion pair
(parameter and argument) is displayed along with the prediction source. As the user continues to
type the next parameter with a dash, the next suggestion pair is displayed until the prediction is
complete.

In the above example, the Az.Tools.Predictor will suggest the parameter and argument based on:

• Examples - Ml-based plugins may learn the most common uses of a cmdlet from documentation examples.
• Reuse - If the parameter and argument pair has been previously typed within the current session,
  the predictor will supply the previously typed argument.
• Syntax - If no examples or history is available, the predictor will display the parameter with the
  Object type for the argument.

Enabling/Disabling

Predictions are enabled and disabled using the Set-PSReadLineOption -PredictionSource <argument>
and may be stored in the users profile. Accepted values for the argument are None, History,
HistoryAndPlugin.

Configuring a predictor

Customizing prediction color, keybindings, and additional plugins is accomplished through PSReadLine
Set-PSReadLineOption and Set-PSReadLineKeyHandler cmdlets. Custom settings may be stored in the
users profile.

[rjmholt]

@TylerLeonhardt do you know if completing a whole line in the editor like this is possible in VSCode?

[TylerLeonhardt]

Yeah it is. Some extensions have "smart snippets" that are better than normal snippets because they can be context aware. Just have to add a CompletionItem to the list of Completions getting sent back to vscode.

whether you're completing a whole line, or just a word, it doesn't really matter. Details:
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_completion

[rjmholt]

Predictions are enabled and disabled using the Set-PSReadLineOption -PredictionSource
and may be stored in the users profile. Accepted values for the argument are None, History,
HistoryAndPlugin.

Unfortunately this occurs at the wrong layer for us. That configures how PSReadLine paints the terminal with predictions, but in order for us to route them through VSCode's UI and present them as options in the client, we need some kind of structured result from the predictor that we can turn into an object to send to VSCode.

@theJasonHelmick or @daxian-dbw what's the best way/API for us to obtain these predictions as returned object results that we can route through VSCode?

[daxian-dbw]

The static type CommandPrediction contains the APIs to obtain prediction results, see https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/Subsystem/CommandPrediction/CommandPrediction.cs#L53
But, to be honest, I'm not very confident how effective those APIs are aligned with the VSCode editor scenario. For the editor experience, it may be better for the prediction to not go through SMA at all, but work in a similar way as IntelliCode.

[TylerLeonhardt]

but work in a similar way as IntelliCode

What do you mean by this, sorry?

[daxian-dbw]

I mean not as a PS module that depends on PSES calling some APIs in S.M.A to get prediction results, but a self-contained component that can just ship with PS extension.

[TylerLeonhardt]

What would happen if the user changes the predictors they are using in the console? I would make the assumption that that would also influence intellisense provided in the extension.

[daxian-dbw]

Yeah, having the PS extension to include every self-contained predictor component won't work.
The current challenge is the feedback to a predictor will almost certainly be different for a terminal client vs. an editor client.

For example, the OnCommandAccepted and OnCommandExecuted feedback make sense to a terminal client, like PSReadLine -- the former is triggered when a user input is accepted for execution; the latter is triggered when the last accepted command line finishes execution and the flow control gets back to PSReadLine. But they obviously don't make sense to an editor client.

New feedback APIs will need to be added to the interface for the editor client, and we will need to allow a predictor implementation to decide what specific feedback it accepts based on the client type (terminal, editor). It would work, but it would also be challenging for a predictor implementation to adapt to both terminal and editor scenarios.