@PeterJones said:
That might be in just the context of a separate thread for each file searched during multi-file searches… but I believe that other ‘background threading’ of searching has also been rejected, though I cannot immediately find an example.
From what I’ve seen, all search in Notepad++ runs through the Scintilla search interface. That by itself makes it impossible to separate search from the GUI thread without re-engineering how search works.
I did, somewhat, re-engineer search for Search++ and for Search in Columns++; for regular expressions, I use the raw data pointer from Scintilla and search it directly with Boost::regex. It might be possible to multi-thread Find in Open Documents that way, but probably not Replace (unless every document were duplicated in memory in the GUI thread, processed in a worker thread, then the whole document replaced in the GUI thread). One of the big hurdles I still have in Search++ is how I’m going to do Find in Files. I do not want to open each file in an off-screen Scintilla control (which I’m pretty sure is what Notepad++ does). The searching sounds simple until you consider code pages and how to locate the match in a Scintilla window if the user asks to see it by clicking in the search results. If I can design that (I just haven’t had the mental space to take on the challenge recently), doing it multi-threaded sounds like it should be possible.
Another frustrating thing is that Boost::regex doesn’t have any sort of progress callback while it is searching. It’s easy enough to do periodic callbacks after finding one instance and before finding the next (each is a separate call to Boost::regex); but often the big delays happen while searching large spans of text where nothing is found. I hope, someday, to take on the challenge of modifying Boost::regex to do a callback instead of the dreaded “too complex” message. That will be a ways down the road.
But any of this is way too much change, and way too likely to cause new bugs, for me to even think of suggesting it as a change to the base program. If anything, I think it would have to be a “parallel” feature, rather than a replacement, which would have to prove itself viable over time… which is, I’d say, appropriate for a plugin.
@shodanx2, if you’re able to code a plugin to show your concept in action so people can try it and actually demonstrate its value and reliability in real world use, that would be the way to go. If you’re throwing all this massive re-design out and thinking “somebody else” will implement it, it’s not likely; consider smaller suggestions that can be integrated without disrupting the interface with which people are familiar or the battle-tested processing of the existing program.
