Improving the Ctrl-H (Replace) experience
-
Suggestion for change to Ctrl-H (Replace) handling.
When a selection is made in a document, and Ctrl-H is entered, the “In selection” option should automatically be set.
If the selection is empty, “In selection” should be unchecked.
-
The current design is that any active selection when Find/Replace is invoked is automatically entered in the Find-what zone. This design is at odds with your suggestion. Since the existing scheme has been in place since Notepad++ was very young, I can’t see it being changed.
-
So basically the answer is the same one from when you asked the same question 5 months ago…will we hear from you again in 5 more months?
-
:-) I had forgotten about that, but it is a recurring nuisance. I’d say that if the user selects several lines of text and hits Ctrl-H, does it really make sense to take that as a Find-What input? Maybe some more smart thinking is required. I’ll check on the progress in five months or so ;-).
-
@Harry-D said:
if the user selects several lines…does it really make sense to take that as a Find-What input
Occasionally yes, but I will accede that it is more common for a multiple line highlight to be headed down the replace In selection path. What would the Find-what zone get set to in such a case (while In selection is auto-checked), do you think?:
- empty
- its previous value
- just set it to the selected-text anyway (a single keypress can wipe it out)
- something else…
-
I think option 3: (the selected text) is not bad. Simply typing over it or dropping (Ctrl-V) something in is plenty of flexibility. And the history feature is pretty nice.
If you’d really want to replace the multi-line thing throughout a file anyway, simply uncheck the “In selection” box.
My guess is that that approach would be more efficient than the way it works now.
Maybe with a little more thinking an even smoother workflow can be achieved. Before the 5 months are over ;-).
-
Having slept on it, implementation would be amazingly simple:
When Ctrl-H is hit: If selected-text-contains-EOL Then check in-selection Else don'tThat is ALL that would need to be changed.
-
I think that was pretty clear from the earlier discussion! :-D
I already implemented your suggestion in my script-based code that alters the behavior I don’t like in the default FInd family of windows. It works, I like it, it makes sense.
I hope your request can be adopted natively into Notepad++'s main code. For this to happen you need to make a real “Issue” out of it, see my boilerplate on how to do this below.
Since you seem adept at coding :-) and Notepad++ is open source, maybe you should try your hand at contributing this change yourself, in the form of a Pull Request. Since it is “amazingly simple”, why not give it a go! Make N++ into the product you want it to be!
HOW-TO: Make a feature request for Notepad++ (or report a bug):
Your best option is to make a feature request or a change-in-functionality request here: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/ by opening a “New issue”.
However, please spend a little time searching to see if your specific request already exists, in which case you can “up-vote” that Open Issue so that in theory it gets more attention. You may also add to an already open Issue any new information you think relevant.
You may search open issues (at the above link) as follows:
- Make sure the Issues “tab” is active
- The box to the right of the Filters dropdown (with the magnifying glass in it) should already have
is:issue is:openin it - Add a space and then your search term to that box and press Enter
-
@Scott-Sumner : Thanks for the guidelines and your support! I will have a go at the issues list, but I won’t be changing any code. That should be left up to people who are at home in this environment, and I am a complete newbie here. Plenty of C-code under my belt, but that was decades ago.
-
-
@Harry-D in all my years using npp a multiline selection going into find box has never been useful. If I could change that behavior I would.
