I'd also love to see tests for the order of the completed options. The first one should be the one with a correct casing, if accessible. Otherwise, the UX would be pretty bad in the multiple casing cases.

We use alphabetical sort with ignoring casing. I don't know how put an object with correct casing on first place. It looks you request creating very complex sorting.
Do anybody really create multiple files/directories with different casing on Unix?

It is very common to have both Makefile and makefile.

It is only one extra press.
I have no idea how to make this weighted sort by simple way 😕

Not exactly simple, but sort insensitive, then compare each element to it's successor in a case sensitive manner, swapping to get case correct first.

Sample 1:
wordToComplete = "aB"

Input:
abcd
aBcd
abde
aBde

Result:
aBcd
aBde
abcd
abde

Sample 2:
wordToComplete = "aB*D"

Input:
abcdef
aBCDef
abcdgh
aBcDgh

Result:
aBCDef
aBcDgh
abcdef
abcdgh

-- If we want the results the sort is not simple as seems - we must take into account wildcards.

Maybe:

1. Get a case-sensitive array and sort it
2. Get a case-insensitive array and sort it
3. Remove elements of (1) array remove from (2) array
4. Add elements of (2) array after end of (1) array

I would:

1. Case-insensitive array sort
2. For each element, compare case insensitive with the next element, if they are equal (should be rare), do a case sensitive wildcard match with the original word to complete to determine the ordering of these 2 elements, swapping if the first fails to match and the second does.

This should be O(n) with an upper bound of 2n, so it's cheaper than 2 sorts.

Is my sample 2 right? If so your suggestion don't work for it. We get:

Result:
aBcd
abcd
aBde
abde

I'm not sure there is a right and wrong result here - only a least surprising, and I think my suggestion prefers case insensitive over the wildcard match which is less surprising, but still orders with some case sensitivity.

At any rate, real world experience will guide us best - try and keep it simple and handle the Makefile/makefile case nicely, and we'll see if it's sufficient.

You don't need to call ToCharArray - that will unnecessarily create an array.

In C#, strings are enumerable, so you would just use foreach (var ch in wordToComplete) ....

First I made a prototype on PowerShell. :-)
Fixed.

You can reasonably assume all characters are letters and pass wordToComplete.Length * 4 when constructing the string builder to avoid growing and copying the buffer.

Thanks! Fixed.

I'm no expert in Unicode - but I can imagine there are letters that have no upper/lowercase variants, so I would avoid the wildcard if ToUpper == ToLower.

German ß for example doesn't have upper in dotnet. (The correct capitalization is probably SS, but dotnet doesn't seem to do it, same as python 2.)
Also the Turkish I is a classical example: if default locale is used, then lower-cased I will be different. We probably can skip these details as a first implementation.

Note that [aa] is a valid regex.

Thanks! Fixed.

Remove, but it might be worth a comment saying we assume wordToComplete is already a wildcard pattern and do not want to escape anything.

Removed.
Comment added above in line 4114.

Previous I removed there if useLiteralPath - Please clarify the if - it seems we should
(1) always escape '[' and ']'
(2) escape StarOrQuestion for useLiteralPath but we did not this previous and don't now.

The word to complete is usually a wildcard pattern (unless the filename specifies -LiteralPath, but I don't think we do that today).

So I think it's probably best to not escape anything. It is probably uncommon to use tab completion and square brackets together, but I'm sure I've done it before, so it might feel broken.

This does mean you need to detect letters inside square brackets and ignore those.

So we leave as is now and add escape StarOrQuestion for useLiteralPath when we'll need?

Yeah, except I missed the code above that already does that, except you changed it.

In reply to: 136893930 [](ancestors = 136893930)

Not used now, right?

Removed.

It seems like the code was correct before - only when we know we have -LiteralPath.