Predictive IntelliSense

[theJasonHelmick]

No description provided.

[iSazonov]

For "packaging" the feature for native utilities see my comment #261 (comment) and #13428

[dragonwolf83]

This can be a bit confusing and conflicting with the term Intellisense. I think most would consider Intellisense to be providing on-typing completion of the command or parameter that you get in ISE and VS Code Editor. This initial implementation is more history completion which is different but related. How will this integrate or supplement with the existing MenuComplete feature?

Right now MenuComplete's UX is poor when compared to editor Intellisense features. This new feature could greatly enhance that feature to get close to real Intellisense. It would be a great default experience when the Predictive/History part is off.

There are really three major parts to this:

• Completion View
• Input Source
• Intelligence / Prediction

Completion Views would be Inline, List, Wide, and Menu (UI Menu emulating intellisense in modern terminals).
Input Sources would be Help, PSReadline History, and future provider plugin.
Prediction would be different methods with it's own plugin for people. When disabled, it should be sorted by Most Recently Used.

That would enable the existing MenuComplete to plug into CompletionViews as an InputSource as a default experience. List or Wide as the default on non-VT terminals with Menu as default on VT terminals. If performance of on-demand typing is a concern it could just default to Tab shortcut.

When Predictive Intellisense is enabled, I could choose History Predictions or Predictive MenuComplete.

A shortcut to toggle between both would be great with the Completion View showing how to switch. I know I want to be able to rapidly use both depending on what I'm doing.

Initial offering still should focus on the predictive history feature, but I think clarifying how this will work with MenuComplete is needed. This would be the perfect first extension to validate the extensibility since the Input Source already exists and just needs to plug into the Completion Views with optional Predictions.

[dragonwolf83]

Should be an option for InlineView alongside a secondary view. Inline and List complement each other. Inline can show the suggested completion with List showing multiple options at once.

Additional Views to consider are

• None
• Wide - the view crtl+space and Format-Wide uses
• Menu - VT Sequence Menu that looks like a real intellisense menu that you get in ISE and VS Code Editors
• TerminalIntegration - Long term, there are feature requests to provide native rendering of completion in Windows Terminal. See Enhance shell autocompletion with a cool new user interface and shell completion protocol microsoft/terminal#3121 and ITerm2-like terminal autocomplete microsoft/terminal#6632

These additional views make me think Inline should be separate On/Off with additional views as a separate configuration with None only affecting what's in its list and not Inline setting.

[theJasonHelmick]

@dragonwolf83 Thank you! We are open to considering additional views as we progress. I agree that InlineView and ListView can be complimentary - currently when using ListView, as you highlight selections, they are displayed fully on the same line as your cursor, similar to InlineView. Appreciate your thoughts and feedback as we move forward.

[dragonwolf83]

Please consider different noun. Subsystem is way too generic and doesn't make sense for discovery. Get-IntellisenseProvider or Get-IntellisenseSystem makes more sense. For easier typing, Get-CompletionProvider would work too.

Also, please prefix this with PS so it is Get-PSIntellisenseProvider

[SteveL-MSFT]

Prediction plugins are using the general PowerShell subsystem model, but that cmdlet should probably be called Get-PSSubsystem, perhaps have a -Type parameter where Prediction is a valid type making it easy to filter? -Type can be added later since we don't support other types currently.

[daxian-dbw]

but that cmdlet should probably be called Get-PSSubsystem

Agreed that we can revisit the cmdlet name.

a -Type parameter where Prediction is a valid type making it easy to filter?

It already does so: Get-Subsystem -Kind CommandPredictor

[theJasonHelmick]

Agreed that name should be Get-PSSubsystem, will leave currently in RFC as Get-Subsystem until final decision.

[daxian-dbw]

The renaming to Get-PSSubsystem is done.

[dragonwolf83]

I mentioned this in separate comment but will add here as well. It would be better to separate out Prediction from Source so that we can use History completion in Most Recently Used order rather than a predictive algorithm.

Prediction Method Examples:

• None
• AI Version 1
• Experimental new AI
• Cloud AI using Azure or AWS AI (maybe not but at least possible to add)

I guess source can be singular or additive so an array:

• History
• Menu
• Plugin

Is the plugin able to register itself to be accepted into the configuration list? I may want to try 3-4 different sources but end up with 1-2 as my defaults. Maybe have the 3rd-4th for specialized work on remote environments.

[SteveL-MSFT]

We should consider using Frecency algorithm rather than most recently used: PowerShell/PSReadLine#1808

[theJasonHelmick]

@daxian-dbw Thoughts on using frecency algorithm versus Most Recent? I find myself expecting frequency.

[daxian-dbw]

The Frecency algorithm mentioned by @SteveL-MSFT takes into account both frequency and how recent the history is.

[SteveL-MSFT]

We should consider using Frecency algorithm rather than most recently used: PowerShell/PSReadLine#1808

[SteveL-MSFT]

Prediction plugins are using the general PowerShell subsystem model, but that cmdlet should probably be called Get-PSSubsystem, perhaps have a -Type parameter where Prediction is a valid type making it easy to filter? -Type can be added later since we don't support other types currently.

[joeyaiello]

I think this is definitely enough for an experimental release of PSReadline, but there's definitely a few questions below that should probably be answered before we accept this as stable.

[joeyaiello]

Suggested change

	Users may change the view at the command line using the keybinding F2 or `Set-PSReadLineOption. The
	Set-PSReadLineOption may be stored in the user's profile.
	Users may change the view at the command line using the keybinding F2 or `Set-PSReadLineOption`.
	The `Set-PSReadLineOption` may be stored in the user's profile.

[joeyaiello]

Suggested change

	- Searching histroy from cmdlet noun.
	- Searching history from cmdlet noun.

[joeyaiello]

@PowerShell/powershell-committee is comfortable moving forward with an experimental implementation of this RFC in PS 7.2 and PSReadline 2.2 previews. We'll make adjustments based on user feedback, re-align the RFC to match the implementation, and merge it as approved once we feel comfortable with the experimental implementation.

[joeyaiello]

Sounds like we removed this one

[joeyaiello]

Should be Get-PSSubsystem throughout the doc:

Suggested change

	`Get-Subsystem` cmdlet is an experimental feature of the `PSSubsystemPluginModel`. To enable the
	`Get-PSSubsystem` cmdlet is an experimental feature of the `PSSubsystemPluginModel`. To enable the

[joeyaiello]

Should be Get-PSSubsystem

Suggested change

	Get-SubSystem -Kind CommandPredictor
	Get-PSSubsystem -Kind CommandPredictor

[joeyaiello]

Just closed this because @theJasonHelmick's original fork was deleted a while back, and his new pushed changes weren't updating here.