Powershell: Autocomplete parameter name request - please show the name for the positionally bound thing immediately right of the cursor

[HumanEquivalentUnit]

Write Get-Content 'file.txt', put the cursor left of the filename, try to autocomplete the -Path parameter name; it's not in the list.

    # move the cursor to the left of the argument, where the parameter name would be 
    Get-Content 'file.txt'
               ^

    # Write a - and try to autocomplete the -Path parameter name
    Get-Content -{ctrl-space} 'file.txt' 
                 ^
    # -Path is not shown in the list of available parameter names

I don't want all the parameter names shown all the time, removing ones which have been used is really useful .. but if it could show the name for whichever parameter is just right next to the cursor and has been bound positionally, that would also be really useful.

Current workaround for long parameter names - try autocomplete, cancel it, comment out the rest of the line, retry autocomplete, choose the name, uncomment the line.

[vexx32]

I am constantly running into this in VS Code as well... It'd be nice to have it be a little more sensible here.

Honestly, I feel as though even just only filtering out already-named parameters would be sufficient. Even if it just listed all the positionally bound ones regardless of where they were, it'd be a huge improvement... But if it could be this sensible, it'd be great!

[SeeminglyScience]

I think the easiest fix would be to exclude already bound positional parameters only when the cursor is at the end of the CommandAst.

[thegooddoctorgonzo]

I'd like to see the auto complete list to include all unless the parameter is already explicitly named.

[vexx32]

I think that might be slightly preferable, if only because there may sometimes be multiple parameters you might want to use positionally or by name, so it's tricky to make an intuitive rule for which ones to hide or not just based on the ones provided, especially where custom functions come into play, which may not always have best practices for parameter ordering, typing, or validation.

[iSazonov]

I can repo in Windows PowerShell but can not in PowerShell Core.

[vexx32]

See below (this is PS Core 6.1 RC1)

-Path is missing as an option.

[iSazonov]

I don't see the problem on Windows.

[vexx32]

What version of PS Core are you running?

Here's my version table:

PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0-rc.1
PSEdition                      Core
GitCommitId                    6.1.0-rc.1
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[HumanEquivalentUnit]

With 6.1.0-rc.1 on Server 2016 it reproduces for me; interestingly:

• If I type -{ctrl-space} to see the menu, -Path is not there
• If I type -{tab} to cycle through the options, -Path is not there
• If I type -Pa{tab} it will autocomplete to -Path

[vexx32]

Yep, looks like the code paths change if you start to specify some of the name. Entering -P{ctrl-space} shows -Path as an option as well.

[iSazonov]

In my test I haven't PSReadline loaded and I see -Path if I type -{tab}. With PSReadline loaded the problem is present.

[SeeminglyScience]

Here's an easier repro that should be the same across profiles as long as you don't have a custom TabExpansion2 function loaded. Tested in 6.1.0-rc1 Windows

$inputString = 'Get-ChildItem - a'
$completion = [System.Management.Automation.CommandCompletion]::CompleteInput(
    $inputString,
    ($inputString.Length - 2),
    @{})

$completion.CompletionMatches.CompletionText -match 'path'
# returns nothing

$inputString = 'Get-ChildItem -'
$completion = [System.Management.Automation.CommandCompletion]::CompleteInput(
    $inputString,
    $inputString.Length,
    @{})

$completion.CompletionMatches.CompletionText -match 'path'
# returns:
# -Path
# -LiteralPath

Also note, this happens in VSCode as well, so I wouldn't say PSReadLine is the difference. Maybe Tab doesn't call the public API when PSReadLine isn't loaded?