@PeterJones said: I think that progress bar for FiF was possible because it’s possible to background a search-through-disk-file action. I know that a single-file search cannot currently have the progress dialog because the underlying search library doesn’t allow you to hook in a process-tracker. The find-in-all-open wouldn’t be able to track inside an individual file because of that limitation, but it might be able to check for cancel between files. Not quite. What’s missing is the possibility — no matter whether it’s from an open document or a file on disk¹ — to monitor progress during a single step of the search. Searching for all occurrences of something is implemented simply by repeatedly searching for the next occurrence of it. You can build a progress bar based on each step of the search. (I do that in Columns++ and Search++, and I believe Notepad++ does it for Find/Replace in Files.) The problem happens when a single search, usually one that never finds a match, takes a long time to complete. There is no straightforward² way to monitor its progress. ¹ Notepad++ implements searching files on disk almost the same as searching open documents: it just loads them into an invisible Scintilla control instead of one of the two visible views. For that matter, I believe documents that are not on a foreground tab must also be loaded into an invisible Scintilla control, but in that case the file is already loaded into a Scintilla document, so attaching that to a Scintilla control is a fast and simple operation for the base program. Plugins can’t do it easily because Notepad++ doesn’t expose the document handles for buffers that aren’t active to plugins (and Don has said that he won’t do that). I say “easily” because it is possible for a plugin to maintain a map of buffer IDs and document handles by carefully monitoring when buffers are activated, opened and closed. (I do it in Columns++ to try to maintain the layout tables for elastic tabstops. Since the change that Replace All in All Open Documents now turns off individual change notifications and just sends a notification that “something changed (none of your business what is was),” that code is mostly obsolete, but I haven’t removed it, if for no other reason, to maintain compatibility with older versions of Notepad++.) ² It’s not impossible. It would require writing a direct search routine rather than relying on Scintilla’s API, and for regular expressions one would either have to modify/fork Boost.regex or do some fancy shenanigans with the iterator class that scans the document.

@docpomus , I am sorry no one replied yet. Usually when that happens, it means that either gup.exe or nppPluginList.dll (in subdirectories of your Notepad++ installation folder) still have the “mark of the web”. To check (and clear) the “mark of the web”, exit Notepad++; right click on the exe or dll file; select Properties; in the General properties tab, if there is a message at the bottom with “unblock”, checkmark that checkbox, and click OK. Do that for either/both files. After that, the plugins should be able to update from Plugins Admin again.

@Adam-Narkiewicz , (sorry for the slow reply: when I first read your post, I was in the middle of something, and couldn’t go looking for the issues, so I hoped that someone else would reply with similar information. Since no one has, I am doing it now.) Honestly, I believe the bug is in step 5: it shouldn’t do that “check for underlying file existence” when you tell it to Close All (or when just closing one file, as in Issue #11866; or when you tell it to reload a file, as in Issue #18718). The developer tried (per this comment) to find a way around this, but hasn’t found a viable solution yet. After asking whether to keep a file in the editor, Notepad++ closes it no matter what my answer is. For me, since you already said “close all”, I don’t see a problem in Notepad++ closing it. I am not convinced it should’ve asked in the first place. Fortunately, if there are unsaved changes – so if you’ve edited the file, so there are unsaved changes to the file that doesn’t exist anymore – it will interrupt the process and ask you to save it, and when it fails, it stops the process (not the best solution, but better than losing data). So this oddity at least won’t let you lose unsaved changes accidentally when doing Close All for files that have disappeared. So that’s something. asks me whether to keep some deleted files open, but not all That does seem problematic, to me. I guess after doing the single check, it finally believes your request to Close All meant to Close All. In conclusion: Since Issue #11866 exists for the single file-close, I don’t think this needs a separate official issue. I’m glad it’s “not particularly annoying” to you, because it could be a long time (if ever) before a solution can be found.