Confirmation or disable the Find All in All Opened Documents

Timothy Baxendale

I tend to have a lot of 150mb text files open at any given time. Multiple versions, flavors, etc. I basically only ever do Find all in Current Document. Since the Find all in All Openened Documents button is right next to it, I sometimes accidentally hit it and then get stuck waiting ages for it to search all the files, especially if it’s a complex regex.

Is there any way for me to disable the button? Or even have a popup after pressing that asks if I’m sure I want to do that? Even when I need to look at another file for the same thing, it’s usually 1 or two other files, not 10+, so it’s easier to go document by document.

PeterJones

@Timothy-Baxendale ,

There isn’t a way to disable the button.

A popup would annoy many users who intentionally hit Find All in All Opened Documents

A workaround would be to use Alt+D instead of clicking the button, because that’s the default accelerator for that button. Since D is nowhere near O on the standard US QWERTY keyboard, the chances of accidentally doing all-opened-docs is near 0.

The Find in Files has a progress dialog with a cancel action. I think it might be a good idea to put in a feature request to have them use that same progress dialog for Find All in All Opened Documents, which would then enable someone (you) to cancel the request if it’s accidentally clicked, or if you decide it’s taking too long. But, as the feature request FAQ explains, make sure to search open and closed issues for similar requests, and don’t create a new request if one already exists – instead, comment on the existing request.

Update: I just remembered: 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.

If you do create (or find and comment on) such a feature request, make sure to come back here and paste the link, so people can easily watch to see if it’s ever implemented.

Coises

@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.