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

[bgshacklett]

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.

[bgshacklett]

A stroke of luck helped me notice that it seems to have something to do with dotfiles being in the directory which completion is acting against. I'll be working on a test shortly.

[bgshacklett]

I've updated the original entry with a test case to show what's happening.

[bgshacklett]

see PowerShell/PowerShell#4694

[bgshacklett]

My apologies for any confusion. I closed this issue with the belief that this repository was no-longer active, hence the reference to the issue in the PowerShell/PowerShell repo. This is still broken, and I believe there are two major problems:

• Ambiguous completion attempts clear out the current level of the completion tree (everything after the last separator).
• The completion engine includes some items which should not be included in a completion attempt; most notably, dotfiles are included when the dot was not specified. E.g.:
  Get-Content ./README.md + Tab will include .README.md.swp if it exists in the same directory. The completion pattern should not match the dot file.

[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]

Thanks for the head's up. The fact that you're relying on the upstream completion engine explains a lot! I can confirm that the inclusion of the dotfile occurs with the PSReadline Module Removed, so the list of completions being returned is definitely an upstream issue.

Unfortunately, moving to v2 that still didn't fix the problem of my original entry being wiped out, but I have a hunch on what's going on. I think that when a list of completions is presented, the code may be trying to bring the cursor back to the position prior to the first character of the first completion in the list. Since the dot file is being included in the completion results, and the index of the location of the dot is at 0, the Replace method wipes out the entire existing entry. If my guess is right, the code that's doing it is at https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/Completion.cs#L260.

So, is this actually an upstream problem, then?

It would be great to get a workaround for this, as I don't see a fix being backported to PS <= 5.1. When I get a moment, I'll spend some time thinking about how that could potentially be implemented.

[lzybkr]

So this is a dupe of #183 then?

I've long gotten into the habit of hitting Ctrl+Space when it happens, mostly because I never saw a solution I was totally happy with.

[bgshacklett]

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