** in search.exclude glob should work the same way it did before

[joshfriend]

Edit: One of my exclusion globs was not valid. "**/**$$*.java": true should be changed to "**/*$$*.java": true

• VSCode Version: 1.11
• OS Version: macOS 10.12.4

Steps to Reproduce:

1. Open global search and enter a query
2. No results found
3. Open a file you know contains a result for that query
4. Search again, results from that file now show up
5. In settings.json set "search.useRipgrep": false
6. Search again, results from all files now show.

My `settings.json`

{
  "window.zoomLevel": 0,
  "window.newWindowDimensions": "maximized",

  "editor.rulers": [80, 120],
  "editor.renderIndentGuides": true,
  "editor.renderWhitespace": "boundary",
  "editor.renderControlCharacters": true,
  "editor.scrollBeyondLastLine": false,
  "editor.trimAutoWhitespace": true,
  "editor.fontFamily": "FiraCode-Regular",
  "editor.fontLigatures": true,

  "files.hotExit": "onExitAndWindowClose",
  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/.DS_Store": true,
    "**/*.class": true,
    "**/**$$*.java": true,
    "**/.gradle/**": true,
    "**/.idea/*": true,
    "**/*.dSYM.zip": true,
    "**/*.ipa": true,
    "**/*.jks": true
  },
  "files.associations": {
    "Fastfile": "ruby",
    "Appfile": "ruby",
    "Podfile": "ruby",
    "*.apib": "markdown"
  },

  "search.exclude": {
    "**/node_modules": true,
    "**/bower_components": true,
    "**/dist": true,
    "**/coverage": true
  },

  "typescript.check.tscVersion": false,
  "editor.wordWrap": true,
  "workbench.colorTheme": "One Dark",
  "workbench.iconTheme": "vs-seti",

  "gitlens.blame.annotation.activeLine": "hover",
  "gitlens.statusBar.enabled": true,
  "gitlens.codeLens.location": "custom",
  "search.useRipgrep": false
}
</details>

[rdmdouglas]

In my settings files.exclude, I had "**/**.csproj*": true. Changing to "**/*.csproj*": true (with only one asterisk instead of two) returned the search as expected. Try something like that.

"**/**$$*.java": true to "**/*$$*.java": true must solve.

[roblourens]

Can you try disabling the excluding settings, and doing a search with ripgrep?

Uncheck the gear icon (selected in this picture)

[roblourens]

The problem is with the second ** in the pattern "**/**$$*.java": true which is actually not a valid usage of **. I can repro it too. Try "**/*$$*.java": true. I guess our other glob code is ok with it though.

[CosmicBara]

Mine won't search either with RipGrep enabled. My search exclusions looks like this:
"search.exclude": { "**hooks/**": true, "**platforms/**": true, "**plugins/**": true, "**resources/**": true, "**www/css/ionic.app.css": true, "**www/css/ionic.app.min.css": true, "**www/lib/**": true },

Note that the rest of my code does not exist in any of those folders, so I'm not sure why it isn't being searched correctly.

[roblourens]

Same reason @GunslingerBara - you have "**hooks/**", etc - ** matches "zero or more directories", so it's not valid next to text. Try replacing those with *.

[rdmdouglas]

@roblourens The most correct would not the VS Code ignore incorrect globs, rather than impact the searches?

[roblourens]

Yeah, I need to either validate them or map ** to * in a case like this. I didn't know they would be so common.

[joshfriend]

@roblourens / @rdmdouglas Thanks for the suggestions. It was an incorrect glob pattern on my "**/**$$*.java": true, pattern. Changing it to "**/*$$*.java": true, fixes the issue.

I'll close this for now. Feel free to reopen if you want to use this issue to discuss how to properly handle incorrect globs.

[ecraig12345]

The current error behavior of "search completely stops working for no apparent reason" leaves a LOT to be desired, especially since incorrect globs used to work (meaning a lot of people have them in config files). Any/all of the following would be better:

• Show an error message in search indicating that a glob is invalid (like the invalid regex error message)
• Use any valid globs for search but ignore the invalid ones
• When the workspace is opened, check the config for invalid globs. If any are found, open the config file and display a message asking the user to fix it.

[roblourens]

The main issue right now is that I don't actually have a great way to validate a glob. The error message doesn't tell me which glob is problematic. The best I can come up with for the near-term is to spawn ripgrep for an empty search once per glob to tell whether it produces an error message. Either ahead of time to validate globs, or after a search to match the error message to a particular glob. It would be great to load the right Rust crate as a native node module sometime later so I can validate globs quickly and in process.

Another possibility would be writing the globs to an ignore file in /tmp, since bad globs in an ignore file don't prevent the search from running.

[BurntSushi]

@roblourens If improving an error message would help you, I'd be open to that. :-)

There's also a possibility that ripgrep should support invalid constructs like **.foo. Even though man gitignore says they are invalid, git actually still supports them. The path forward is somewhat unclear. See: BurntSushi/ripgrep#373

[roblourens]

The resolution here is

• Surfacing some rg error messages in the VS Code UI
• Surfacing all rg stderr output in an output channel
• Updating rg to get a better error message

[sandy081]

@roblourens I see the error in output channel but not anywhere else.. Is it expected?