File completion in presence of hidden files

[dezifit]

If a subfolder contains a hidden file (say ".test") as well as a regular file with the same name ("test" in this case), a file completion starting from the parent directory just clears the file name (everything after the backslash).

Pressing TAB on del config\te results in del config\. Turning off match-hidden-files doesn't change this behaviour. Maybe there is another setting to prevent this, but having it as default seems wrong.

Version: v1.4.3.67deea

[chrisant996]

@dezifit Thanks for reporting this.

Interesting: the problem only happens with the complete command; both menu-complete and clink-select-complete behave as expected and result in del config\test .

[chrisant996]

Oh, of course...

The root cause

Commit a648688 on Dec 2, 2020 (more than 2 years ago) isn't hooked up correctly with respect to how it handles . prefix in file names.

Here is what's happening:

It has nothing to do with the "hidden file attribute". Instead it's purely about the quirk that in the Windows file system APIs both test and .test are considered matches for te*.

❯ md testdir
❯ echo foo>testdir\test
❯ echo foo>testdir\.test
❯ dir /b testdir\te*
test
.test
❯ del testdir\te

Invoking complete on the last line of the above sample results in the following list of matches, just as the dir /b testdir\te* command does:

testdir\test
testdir\.test

And the complete command (which is bound to Tab in your configuration) always inserts the longest common prefix from the matches. The longest common prefix from test and .test is an empty string, and that's why it goes from testdir\te to testdir\.

Here is the challenge:

For people used to how Windows works and how completion normally works in CMD, it's important for menu-complete to cycle through both test and .test when the input is testdir\te. This is basic backward compatibility.

But that leads to a conflict:

• Since menu-complete should include .test, it makes sense for possible-completions to include .test.
• Since complete should not include .test (because of its longest common prefix behavior), it also makes sense for possible-completions to exclude .test.

There is a bug in how the menu-complete compatibility is hooked up -- and that's why possible-completions shows .test last, when normally it should show up first.

What needs to happen

Clearly complete needs to not treat .test as a match for testdir\te.

I think the best thing to do is the following:

1. The complete command needs to omit .test, but the possible-completions and menu-complete commands should continue include .test in the list of possible completions.
2. Add a setting that can optionally completely disable the Windows . prefix compatibility in possible-completions and menu-complete.

[chrisant996]

I'm working on this, but it's complicated. I hope to have a fix sometime tomorrow.