Powershell: [Feature Suggestion] Add slightly more intelligent tab completion

[kilasuit]

Originally opened at https://github.com/lzybkr/PSReadLine/issues/712

This is definitely less of an issue and more of a feature request/suggestion.

The scenario that I see that would be useful would be if you are typing at the console and then are Piping to another command.

so for example

Get-Service | <tab>

would then intelligently suggest the below first

Get-Service | Stop-Service
Get-Service | Restart-Service
Get-Service | Start-Service

I wasn't exactly sure if this would be an extension to PSReadline or whether this would be better placed directly in the main PowerShell Repository, however this would also potentialy be something that I think should (if possible) be able to be backported.
This could also allow it to become a more extensible model that would allow module authors to do things like

$GetParams = @{}
$setParams = @{}
Get-CUItem @getParams | Set-CUItem @setParams

etc etc

this is only a basic example but hopefully makes some sense

I'd actually be quite willing to work on this if given the right pointers on where to start as I expect this would take me some time but I think this would be a hugely beneficial thing to have both interactively and when writing scripts.

[vexx32]

Hmm. So effectively you'd want PSReadline to look at the cmdlet that comes before the pipe and try to match it with another one that carries the same noun, but a different verb.

I'd also suggest having ForEach-Object and Where-Object and suchlike as part of a 'default set' that get suggested for all commands.

[SteveL-MSFT]

This request is related to our RFC to expose extensibility to intellisense to expose this type of capability without it tied specifically to PSReadLine.

[lzybkr]

IMO, this feature is shouldn't require or rely on any sort of extensibility.

The basic idea is - command completion uses the OutputType specified by the previous command to filter the list of possibilities.

This very scenario is why OutputType was added in the first place, we just never got around to adding the necessary support in command completion.

@kilasuit - since you're willing to work on it, I think:

• Start here - if this method is called for your scenario, then things will be a bit easier. It should definitely be called if a partial command name is specified.
• If this method is not hit (e.g. you don't have a partial command name), I think you'll need to add some code near here. It's really messy - basically a bunch of heuristics to guide completion, it's hard to provide much guidance here without really digging in.
• Use this method passing the CommandAst of the previous command in the pipeline to get the inferred types to help guide completion.

I do think some care will be needed to not impact performance too much. We might need to exclude some types like object, PSObject, and string because basically every command supports those types in the pipeline. If tools like VSCode automatically invoke completion after the |, there could be a big impact on the user experience.

[SteveL-MSFT]

@lzybkr the point of extensibility is that individuals can develop different algorithms for completion and people can try out what they prefer

[lzybkr]

@SteveL-MSFT - my take on the RFC is that it is basically the same as defining your own function TabExpansion or TabExpansion2. That seems like the wrong approach to introduce an incremental improvement to the current completion infrastructure.

[kilasuit]

Just to update on this - I am looking to start the work on this based on OutputType expansion in the coming days, thanks for the pointers @lzybkr

[kilasuit]

I am going to attack this as part of hacktoberfest attempts

[kilasuit]

@theJasonHelmick this would be one for your Shell Project.
I do still want to tackle this but have yet to get chance to get started on this