[savetheclocktower]

…from editors whose paths are not matched by the current path inclusions.

Fixes #1379.

The find-and-replace package wants to do a good job. It wants to ensure that your project-wide search results are a real-time reflection of the state of the workspace.

So when you search for dev in site/templates, it doesn't just do a one-off search. It also listens for changes to the active editor and keeps its results current in the results view. If sites/templates/foo.ejs didn't contain the string dev when you did the search… but then you edited the file and added the word dev somewhere… it will pop up in the results!

This is handy except when it shouldn't actually be there. The initial search — the one that happened in the background using either ripgrep or the other strategy (forget what it is) — took path inclusions/exclusions into account. The incremental re-search — the one that happens when you make changes to the active buffer — appears not to consider those path patterns. So that's what we need to fix.

This is related to #1298. (I thought it might've been caused by #1298, but I can't figure out how, so I think this has just always been an issue.) In both cases, we're bypassing the efficient project-wide search (with a dedicated tool) to perform a manual single-buffer search. In both cases, the bypass process ended up also bypassing any path patterns that may have been specified, causing a bug.

We had to introduce some new logic to fix #1298, and luckily we're able to reuse it here. Since atom.workspace can already take our path pattern syntax and convert it into minimatch objects, all we need to do is expose the ability to ask “hypothetically, would path X be excluded by path pattern list Y?” from the find-and-replace package. I've added a new atom.workspace.filePathMatchesPatterns method to do just that.

The new method has specs to prove it works as intended.

Only a little new code is added in find-and-replace itself: before we add a set of results to the project-search results list, we ensure that the file path it came from matches our current path inclusions/exclusions list. In many cases, this checking is redundant, since ripgrep (or the other thing) will already be ignoring those paths… but that's OK.

[savetheclocktower]

@confused-Techie, I opened this PR against master because, as far as I can tell, the bug has existed on master this whole time. If you want to test it with your Electron-30 Pulsar instance, you can do this:

• Quit Pulsar
• Check out the pristine-pulsar-next branch and do the yarn install && yarn build dance
• Set ATOM_DEV_RESOURCE_PATH to the full path to where you've checked it out
• Run pulsar --dev . and verify that you're running code from the expected directory (one quick way would be to go to devtools -> Sources, press Ctrl+O, type (e.g.) workspace.js, and ensure the path that comes up points to the source code and not to a path with app.asar in it)
• Cherry-pick c28cff1 on top of that branch, then reload your Pulsar window
• Try the original test case from [pulsar-next] Find & Replace adding in files from outside the filter #1379 again

[confused-Techie]

@savetheclocktower Thanks for getting to this so quickly! This does indeed fix my original test case and we should go ahead and merge it, awesome work!