Confusing that "replace on disk" sometimes includes files listed in working set

[peterflynn]

1. Add enough files to your working set to pass FindInFilesUI.MAX_IN_MEMORY (you can edit it locally to make this easier)
2. Add two files into the working set that both contain a given string
3. Restart Brackets, leaving selection on the first file -- so the second file has not actually been opened yet
4. Do a Replace In Files on that string
5. Accept the dialog that says Brackets will modify "unopened files" on disk

Result: The 1st file you added to the working set is dirty, but the 2nd file isn't. The 2nd file has been modified directly on disk.

Technically it's true that the 2nd file hasn't been opened yet, but it probably doesn't seem that way to the user.

We can either:
(a) tweak the string to make this more clear, or
(b) change FindUtils._doReplaceInOneFile() to always force-open files that are already listed in the working set (which hopefully won't lead to us overshooting MAX_IN_MEMORY by too much...)

[njx]

Good point. (b) sounds right to me and shouldn't be too hard to implement.

[njx]

(In fact I think that was the original intent, and I just forgot to implement it.)

[njx]

Oh, I see the problem...it's in the working set but not "open". I missed that little detail. So this is really an edge case, not as big a deal as I originally thought. Still, easy enough to fix.

[njx]

Removing "[ReplaceInFiles]" tag since this is now in master.

[njx]

Marking low priority, fix in progress to me - fix is in #8172

[redmunds]

FBNC back to @peterflynn .