Tab completion fails in some cases; Cursor drops back to parent folder.

I have a test case where I can reproduce the issue. Unfortunately, It happens to be a directory full of code that I don’t, yet, have rights to release. I have not been able to isolate the exact scenario that causes the issue, thus I have not been able to reproduce this issue in a controlled circumstance.

The parent path of the folder that I’m currently experiencing problems with resides under C:\Program Files\WindowsPowerShell\Modules\.

Update: I’ve come up with a full test case. It appears that it’s related to a hidden dotfile in the directory with a large ammount of the name matching another file. This commonly happens with Vim, as it creates “.swp” files in this way as it’s working on a file.

Steps to reproduce:

1. Create a file structure to recreate the problem:

   1. Make the parent directory:

   cd ~
   New-Item -Type Directory -Path tmp\PSReadLine_260
   cd tmp\PSReadLine_260
   

   1. Create some test files in the directory.

   New-Item -Type File -Path testFileOne.txt
   New-Item -Type File -Path testFileTwo.txt
   New-Item -Type File -Path testFileThree.txt
   

   1. Create the file that will break tab completion (note the dot at the beginning).

   New-Item -Type File -Path .testFileOne.txt
   attrib +H .testFileOne.txt
   

2. Enter gc t

3. Press the Tab key

Expected behavior: The resultant command line should read: > gc .\testFile

Actual behavior: The resultant command line reads: > gc .\

Typing enough of the file name will cause completion to function properly. gc testFi<Tab> will result in: gc .\ gc testFil<Tab> will result in: gc .\testFile

Without knowing the codebase, this makes me wonder if there’s a Compare-Object occurring with a SyncWindow size that’s too small.

[lzybkr]

Please try a recent build, e.g. this one, there have been improvements in the handling of ambiguous completions.

I haven’t looked at why completing ./README.md<TAB> returns .README.md.swp, but PSReadLine does not generate completions, PowerShell does that so that all hosts can benefit (e.g. ISE, VSCode, PSReadLine, etc.)

And no worries about appearing inactive - I get busy with other things, this is a side project for me. The version in the PowerShell tree is a fork that only works for PowerShell Core - this version supports Windows PowerShell and now PowerShell Core.

[bgshacklett]

Hmm, it looks that way, yes. I’ll go ahead and close this issue in favor of #183 .