Steps to Reproduce:
Since Windows NTFS is not a case-sensitive file system, the expected results is that I can search in files using any case in the 'files to include'/'files to exclude'.
Changing this will be a regression for people that expect this behaviour, so if we ever want to change this it needs to be behind an option. It would be nicer if in the glob pattern itself you could define if it should match case sensitive or not (similar to how this is possible in RegExp).
Yeah, it would be great if there was an option (button) to toggle the case-sensitivity on the glob patterns
I imagine them remaining case-sensitive by default, and being able to add
"search.exclude": { "Foo/**": { caseInsensitive: true } }.
And in the search viewlet, either there's a button in the include/exclude boxes to set case sensitivity or a setting. Maybe this is all overkill, I don't know. It would be a lot easier to make all globs case-insensitive. I don't know how many people want to exclude FOO/ but not foo/.
@bpasero Looking at this again, I think defining this per pattern is overkill. gitignore is case-insensitive. I doubt many people depend on case-sensitive patterns. I think one of these options would be simpler:
Thoughts? This would apply to patterns in ripgrep and glob.ts. If it's an issue for internal use of glob.ts, it would be easy to keep an option there.
Maybe we should turn this around and make all patterns case-insensitive unless you provide a separate option, e.g. "search.exclude": { "Foo/**": { caseSensitive: true } }?
Sure, but is enabling it individually per glob worth it, vs something like a global setting?
@roblourens actually given more thought on it, we cannot add this as option to the glob because e.g. in our extension API a glob pattern passes as simple string. The only way how we could support it generally was with some new syntax as part of the glob string (like the /i option for regex). Given that, a setting might be our only choice after all.
This causes an issue with TypeScript. An already existing project I have has the file names with the class case, so User.ts for the User class. This becomes user.js after compiling and the glob breaks, so the pattern to hide TypeScript generated files (as stated on Microsoft鈥檚 own site: https://code.visualstudio.com/docs/languages/typescript) is bad advice for Windows users since this case sensitivity causes it to fail. This should never be the case on Windows where file names are not case sensitive.
This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!
Let's reopen, I think we did not conclude what to do here.
Yes, I still plan to do this, whenever I have time to update ripgrep.
I plan to make globs case-insensitive by default and add a setting to make them case-sensitive.
Does this just affect files.exclude/search.exclude/search viewlet? Where should a setting go, to make it obvious that it impacts globs in all of these places? createFileSystemWatcher and findFiles from the extension host also take globs. There could be a case sensitivity option as part of the API, or it can follow the user setting.
It would be great if at least the search sidebar had toggles like this:

I just ran into this issue. Very annoying that * user *.php does not find UserProfile.php in "files to include". I have to use * User *.php.
This has been open for _three years_. Can we get a fix for it, please?
Searched for dockerfile in "files to include" and only got partial results. Searched for Dockerfile and got the rest. This is a poor experience under Windows and there are no workarounds that can be used to search for all valid forms of a particular file.
Windows APIs and pretty much all Windows applications are case insensitive when handling filenames. VSCode is not properly conforming to this and should be fixed to avoid unexpected results and users who are mislead to believe they have seen all files, but instead have seen only a subset
Seems like this behavior should be OS specific or perhaps follow a model like regex. There are different ways but usually some suffix to the search string.
Perhaps use something like \i for case-insensitive and \c for explicit case-sensitive searches.
@tolgabalci wrote:
... This is a poor experience under Windows and there are no workarounds that can be used to search for all valid forms of a particular file...
Of course there are workarounds:
Look at this little beauty for the string "VeryLongFilePathThatGoesOnAndOnAndOn"
[Vv][Ee][Rr][Yy][Ll][Oo][Nn][Gg][Ff][Ii][Ll][Ee][Pp][Aa][Tt][Hh][Tt][Hh][Aa][Tt][Gg][Oo][Ee][Ss][Oo][Nn][Aa][Nn][Dd][Oo][Nn][Aa][Nn][Dd][Oo][Nn]
Or even better: 馃槒
{V,v}{E,e}{R,r}{Y,y}{L,l}{O,o}{N,n}{G,g}{F,f}{I,i}{L,l}{E,e}{P,p}{A,a}{T,t}{H,h}{T,t}{H,h}{A,a}{T,t}{G,g}{O,o}{E,e}{S,s}{O,o}{N,n}{A,a}{N,n}{D,d}{O,o}{N,n}{A,a}{N,n}{D,d}{O,o}{N,n}
馃お
/s
Ok, I ~essentially~ totally agree with you 馃槂
I would prefer a toggle option in the search gui for case, and not let it be determined by current OS or a settings entry, as sometimes on windows you do need case sensitive file path searches (e.g. when accessing a wsl filesystem from windows through wsl$ or even on a ntfs or fat32 LFN volume which actually does store the names case sensitive so why not use it*)
*On windows case sensitive searches can help you discover crossplatform problematic include files.
Most helpful comment
It would be great if at least the search sidebar had toggles like this: