Summary of the new feature / enhancement
Story
As a PowerShell tool developer, I want to determine what command is associated with a parameter found via CompleteInput, so I can resolve and display the help for that parameter in intellisense
For example, in the PowerShell Extension for VSCode, I should be able to display the parameter help for Uri when hovered or in the tab completion info:
Proposed technical implementation details (optional)
Problem
Currently, the AST logic that does completion input for parameters does not expose what command it found for the purposes of the parameter resolution, only the matching parameters.
|
if (firstSplatUse is not null && firstSplatUse.Parent is CommandAst command) |
|
{ |
|
var binding = new PseudoParameterBinder() |
|
.DoPseudoParameterBinding( |
|
command, |
|
pipeArgumentType: null, |
|
paramAstAtCursor: null, |
|
PseudoParameterBinder.BindingType.ParameterCompletion); |
|
|
|
if (binding is null) |
|
{ |
|
return null; |
|
} |
|
|
|
var results = new List<CompletionResult>(); |
|
foreach (var parameter in binding.UnboundParameters) |
|
{ |
|
if (!excludedKeys.Contains(parameter.Parameter.Name) |
|
&& (wordToComplete is null || parameter.Parameter.Name.StartsWith(wordToComplete, StringComparison.OrdinalIgnoreCase))) |
|
{ |
|
results.Add(new CompletionResult(parameter.Parameter.Name, parameter.Parameter.Name, CompletionResultType.ParameterName, $"[{parameter.Parameter.Type.Name}]")); |
|
} |
|
} |
|
|
|
if (results.Count > 0) |
|
{ |
|
return results; |
|
} |
|
} |
There are several code paths where parameter resolution occurs, pretty much wherever PseudoParameterBinding is present.
|
var binding = new PseudoParameterBinder().DoPseudoParameterBinding(commandAst, null, null, bindingType: PseudoParameterBinder.BindingType.ArgumentCompletion); |
Suggested Implementation
Add a out CommandAst? boundCommand argument for SMA.CommandCompletion.CompleteInput that allows specification of an argument that will output a CommandAst of the bound command if the completion was a parameter completion. Update existing CompleteInput overrides to call this method, ignoring the boundcommand parameter. This keeps the API binary compatible.
I'm willing to PR the changes.
NOTE: This change would be complimentary to #25108, to be able to look up command help separately and provide a help link to the bound command in addition to what the tooltip help provides.
CC @MartinGC94 @jborean93 @andyleejordan for feedback or alternate implementation suggestions.
The biggest issue I see is that PSES/etc. would have to either use reflection or ship a separate 7.Next binary to use this feature in the near term.
Summary of the new feature / enhancement
Story
For example, in the PowerShell Extension for VSCode, I should be able to display the parameter help for Uri when hovered or in the tab completion info:
Proposed technical implementation details (optional)
Problem
Currently, the AST logic that does completion input for parameters does not expose what command it found for the purposes of the parameter resolution, only the matching parameters.
PowerShell/src/System.Management.Automation/engine/CommandCompletion/CompletionCompleters.cs
Lines 8378 to 8406 in b801027
There are several code paths where parameter resolution occurs, pretty much wherever
PseudoParameterBindingis present.PowerShell/src/System.Management.Automation/engine/CommandCompletion/CompletionCompleters.cs
Line 8210 in b801027
Suggested Implementation
Add a
out CommandAst? boundCommandargument forSMA.CommandCompletion.CompleteInputthat allows specification of an argument that will output aCommandAstof the bound command if the completion was a parameter completion. Update existingCompleteInputoverrides to call this method, ignoring theboundcommandparameter. This keeps the API binary compatible.I'm willing to PR the changes.
NOTE: This change would be complimentary to #25108, to be able to look up command help separately and provide a help link to the bound command in addition to what the tooltip help provides.
CC @MartinGC94 @jborean93 @andyleejordan for feedback or alternate implementation suggestions.
The biggest issue I see is that PSES/etc. would have to either use reflection or ship a separate 7.Next binary to use this feature in the near term.