Dot folders in tab completion list

[dmitri-gb]

> set YORICOMPLETELISTALL=1
> mkdir aaa .abb
> cd a<TAB>
aaa\   ABB~1\

I think the above use case could be improved. I see two options:

1. Do not suggest the .abb (ABB~1) directory at all. If I wanted to change into it, I would have started with ..
2. Suggest .abb, but write it as such, instead of using the 8.3 filename.

Personally, I would prefer the first option.

[malxau]

Out of interest, would your answer be the same if you weren't using YORICOMPLETELISTALL?

Short file names are always a bit of a mess where there's no right answer for what to do with them. Depending on context, they're either a completely valid file name or they don't exist at all. I can't help but think this behavior is annoying to you because you know that you intended to specify a long name, but the system doesn't generically know that. If you typed C:\Progra~, then you probably wanted a short name, and if the system only matches long names it would provide no matches.

The completion code already had to deal with this because FindFirstFile will return a match if either the long or the short name match, so it needed to figure out which name actually matched. I think changing this behavior (for all cases) means deleting the below two lines but it's not clear to me that always ignoring short names is the right thing to do.

https://github.com/malxau/yori/blob/0d45fba9ca81a5ad43d8c1ccc0969619606420db/sh/complete.c#L798-L799

[dmitri-gb]

Out of interest, would your answer be the same if you weren't using YORICOMPLETELISTALL?

Probably, although that case might be a bit less annoying, as I can just press tab again until it shows the folder that I want. With ListAll=1 I need to type more letters to disambiguate the choice, which is... well... more time consuming 😄

If you typed C:\Progra~, then you probably wanted a short name, and if the system only matches long names it would provide no matches.

it's not clear to me that always ignoring short names is the right thing to do

I have personally never found short names to be of any use (granted, my experience with computers begins with the Windows XP era), and I don't see a scenario where I'd want the shell to complete a short name. In this example, I can see it working such that if the list of matching names has exactly one long name, then immediatly complete to it, otherwise show the list, but maybe that's a bit too arbitrary.

[malxau]

Fair enough. I'm not entirely convinced but since you use this mode and I don't, I'll defer to your judgement. I pushed commit 5ff57856f35b1b0c37703bffb0652b07f17a79b9 for this.

As far as short names being useful, I don't think length of time using Windows changes the answer. To me they're very frustrating because maintaining two links means the file system has to do everything twice, slowing things down, and the most likely result of doing so is confusion when an expression matches things the user doesn't expect. I'm still scarred from running erase *.htm and having it delete everything ending in .html . The reason this happens isn't obvious unless you're very familiar with what Windows is doing. My systems typically have short file name generation disabled.

What I wish people really understood about these things is the stated reason for ever having them is to be compatible with DOS programs, but DOS programs don't need them, because DOS programs will always generate an 8.3 name, so don't need an autogenerated pair. The whole reason for this feature is to allow a Win32 program to generate a file that DOS wouldn't understand and still let DOS find the file - it's an interoperability thing. These days it's maintained because Win32 programs could see these names, and in hindsight, they should have been fully invisible to Win32, only existing in an alternate universe that DOS programs could see. It was very frustrating to me that XP 64 shipped without DOS, but still generating short file names by default.

[malxau]

This should be fixed in 1.50, released today. Please let me know if there are further related issues.