You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.
Add enough files to your working set to pass FindInFilesUI.MAX_IN_MEMORY (you can edit it locally to make this easier)
Add two files into the working set that both contain a given string
Restart Brackets, leaving selection on the first file -- so the second file has not actually been opened yet
Do a Replace In Files on that string
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...)
The text was updated successfully, but these errors were encountered:
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
changed the title
[ReplaceInFiles] Confusing that "replace on disk" sometimes includes files listed in working set
Confusing that "replace on disk" sometimes includes files listed in working set
Jun 19, 2014
FindInFilesUI.MAX_IN_MEMORY
(you can edit it locally to make this easier)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 overshootingMAX_IN_MEMORY
by too much...)The text was updated successfully, but these errors were encountered: