Find & Replace & Mark re-organization proposal
-
- run the auto-count algorithm in another thread
Multi-threaded search has been rejected on the grounds that it breaks other features:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8329
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/3562#issuecomment-2242694908(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.)
If your live-count solution relies on one or more new threads, don’t count on it being accepted.
I think (but am not sure) that all your suggestions for “timeouts” and the like would also require threads, which would probably make them a no-go as well.On my 156 megabytes file that is 39 milliseconds.
normal-search=
hrefis not a complicated regular expression, and thus you have a 39ms strawman there. As I said, I have seem minutes pass while searching. If you haven’t experienced that, be thankful. But understand that freezing other people’s search dialogs for minutes before they can search, just because you want automatic “live” count, is not going to be accepted. (If that auto-count were limited to mode=normal searches, maybe, just maybe, it would be safe enough. But I’m still doubtful.) -
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.
-
-
but counting 1024 character really is not obvious
Notepad++ counts for you:
The pictured selection is 992 characters, and thus not quite past the threshold.
-
Today I Learned. 😀
-
Notepad++ counts for you
This is true; my point about “feel” was that, at least for me, if I select a “bunch” of characters with a search in mind as the next action, of course I want it to be within that selection. Again, everyone’s “bunch” could be a different number (which is why the option is configurable), and it isn’t a hard number in your mind, but there has to be a definite number for the software.
TL;DR: I have never watched the
Sel:item in the status bar when making a selection for this purpose. -
it isn’t a hard number in your mind, but there has to be a definite number for the software.
Of course. And so you select what you “feel” is about right for your limit, and use the
Selnumber (rounded appropriately) to set the hard number for the preference entry. -
@PeterJones
I agree with Alan, to make this intuitive you have to be able to go by feel.Consider the following two selections
One of these is In Selection the other one is not.
And you don’t usually get a side-by-side and one of these two will wreck your file if you don’t notice what mode you were when you press Replace All.
One easy way to make this intuitive, would be to flip the text on the button and also to change the button’s colour, so you don’t have to read it, you will feel it.
On the other hand, separate buttons for “in selection” and “in document” will not even need you to feel it, it will move to intent in your muscle memory. Both of these could exist as different layouts that you can toggle.
As for the “auto-count” algorithm.
There is a way to make this work.
I understand that you call by 39 millisecond search on a 156 megabyte file a “strawman” but you have to understand that, you can make arbitrary long regex time if you want.
There is a single thread solution to make this work.
You call the count algorithm but every 4 or 8 millisecond you call whatever the equivalent of DoEvents is in scintilla.
Combine this with the circuit breakers I described above and I think it’s very feasible and won’t freeze the UI. I think some other long running features in notepad++ could benefit from this. Because when I had this 156MB file loaded in np++ earlier, there was a lot of misbehaviour. Lots of freezing when simple moving the window, even though nothing changed on screen, just a simple translation.
Also this is just a particularly crunchy bit of the problem, the rest of the layout redesign doesn’t have any difficulties except for some the new proposed features (boolean, fuzzy and semantic search are each their own can of worms).
-
There is a single thread solution to make this work.
You call the count algorithm but every 4 or 8 millisecond you call whatever the equivalent of DoEvents is in scintilla.
Scintilla calls Boost::regex. Boost::regex does not return until it either finds a match, exhausts the input, or trips its internal “this looks like it might be an infinite loop” flag.
There is nowhere to put that “DoEvents” call (which wouldn’t be a call to Scintilla, it would be a return from a dialog or window procedure with a zero-length timer set to call the procedure again after Windows updates).
You can (as in my linked example) do a periodic return between one search and the next, but you can’t interrupt a single, long-running search. That’s annoying in my application, but would be fatal as proposed in this dialog.
-
the rest of the layout redesign doesn’t have any difficulties except for some the new proposed features
You and I will have to disagree on that statement, because I know I cannot convince you, and don’t feel like arguing with you anymore (hence the post that was live for a few minutes before I deleted it; it’s just not worth the effort).
But at this point, I want to emphasize @Coises’ earlier suggestion: Make it a plugin at first. Try it out, take it round the block, learn the difficulties with the extra features you want, get it better, get it bulletproof. All the mockups in the world will count as nothing compared to such real-world proof. If people like it, maybe it will be to the 2020s what TextFX was to the 2010s: a plugin that a huge population of users installed, and that they still ask about a decade after the author abandoned it.
But if you want suggestions
- start simple, with just reworking the “look and feel”, without trying to add the extra features like the live count
- redo your icon design: the industrial/bolted-plate design looks/feels nothing like anything else in Notepad++, so it doesn’t seem like it’s part of the same app. Design some icons similar to the Fluent toolbar icons, and it would at least fit in with one of the existing GUI options.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login