Find/Replace Window blocking results ...

Marshall-Brooks

First off, NPP is a great program. I did a search and I’m fine with submitting a feature request, but I didn’t know if this was implemented.

Find/Replace dialog seems like it would work well in a multi-monitor situation.

In single-monitor, if I have the dialog at the right of the screen and have a long line of text with the search result at the end of the line, the result sometime is shown behind the dialog, so I have to move the dialog to view the result.

It would be nice if NPP either slightly moved the dialog so that the found text was visible, or (probably better) if it scrolled the window text so that the active line was not behind the dialog.

Is there a hidden setting that accomplishes this?

Debug info:
Notepad++ v8.8.1 (64-bit)
Build time : May 3 2025 - 18:41:09
Scintilla/Lexilla included : 5.5.6/5.4.4
Boost Regex included : 1_85
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : “Z:_Brooks Work\FM ExtendScript\Scripts_2025\OPS_JG_Update_Variables.jsx”
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : ON
Placeholders : OFF
Scintilla Rendering Mode : SC_TECHNOLOGY_DEFAULT (0)
Multi-instance Mode : monoInst
File Status Auto-Detection : cdEnabledNew (for current file/tab only)
Dark Mode : OFF
OS Name : Windows 11 Enterprise (64-bit)
OS Version : 23H2
OS Build : 22631.5472
Current ANSI codepage : 1252
Plugins :
JSMinNPP (1.1905.1)
mimeTools (3.1)
NppConverter (4.6)
NppExport (0.4)
NPPJSONViewer (1.34)
XMLTools (3.1.1.13)

PeterJones

@Marshall-Brooks said in Find/Replace Window blocking results ...:

f I have the dialog at the right of the screen and have a long line of text with the search result at the end of the line, the result sometime is shown behind the dialog, so I have to move the dialog to view the result.

It would be nice if NPP either slightly moved the dialog so that the found text was visible, or (probably better) if it scrolled the window text so that the active line was not behind the dialog.

Is there a hidden setting that accomplishes this?

No such feature exists. The “transparency” setting in the dialog is supposed to help with this.

I’m fine with submitting a feature request

Feel free. (Personally, I doubt it will be implemented, because the transparency already exists; but I could be wrong.)

Coises

@Marshall-Brooks said in Find/Replace Window blocking results ...:

In single-monitor, if I have the dialog at the right of the screen and have a long line of text with the search result at the end of the line, the result sometime is shown behind the dialog, so I have to move the dialog to view the result.

I saw that you commented on Search function impracticality #10438. Though your problem isn’t quite the same as the original poster’s, it’s surely in the same vein; and if it were fixed, the fix would probably happen in the same place in the code. So, personally, I think it’s appropriate there.

I’m wondering if there is enough interest in this to attempt a fix. It doesn’t look like it should be all that hard (but looks can be deceiving). I’m uncertain, though, whether these two annoyances can be addressed in a “one size fits all” manner, or whether what some people want, others would hate. Adding more settings is typically a hard sell.

For what it’s worth, you don’t need to do the Find All in your workaround; you can just move the dialog to the bottom of your screen and drag the bottom edge of the Notepad++ window upward to clear it; or drag the search dialog to the left or right edge of your screen and drag the vertical edges of Notepad++ to use the rest of the width on your desktop.

Marshall-Brooks

@PeterJones - I didn’t think about the transparency feature working to help with this. It was on by default and I found it distracting (made me thing the search window stopped working for some reason.)

@Coises said in Find/Replace Window blocking results ...:

Adding more settings is typically a hard sell.

Personally, I like the idea of a setting for “Center Find Results - Yes/No”, but the tough thing is deciding which value should be the default.

@Coises said in Find/Replace Window blocking results ...:

you can just move the dialog to the bottom of your screen and drag the bottom edge of the Notepad++ window upward to clear it.

Brilliant - Thank you!!!

Coises

I’m willing to work toward creating a pull request that could resolve the issues in:

if there is agreement about how it should work.

I think we can all agree (?) that in an ideal world we would get all of these behaviors after a successful search:

The entire found text is visible.
Some context is visible on all four sides (unless there is none, e.g., there is no context above the first line).
Don’t scroll vertically if it’s not necessary.
Don’t scroll horizontally if it’s not necessary.
Visible includes not being hidden behind the search dialog.

Probably we can agree:

If the found text is too wide or too tall to fit the screen, make the caret visible.
If the found text will fit on the screen but all of the desired context won’t, show all of the found text and use the space left for context.
If scrolling is necessary and the text and context fit on the screen, take the search direction into account so as to increase the possibility that subsequent searches won’t require scrolling. (I.e., if searching forward, put the found text near the top left; if seaching backward, near the bottom right.)

But:

If the found text will fit on the screen but all of the desired context won’t, do we divide the context half and half top/bottom and/or left/right? Prioritize bottom/right? Something else?
How much vertical context? One line? Two? Three? As much as possible (i.e., center vertically)? Does it need to be user-controllable?
How much horizontal context? Five characters? Ten? As much as possible (i.e., center horizontally)? Does it need to be user-controllable?
If the found text is visible without scrolling, but the preferred amount of context isn’t, do we scroll just to show the context? Is there a separate threshold (a minimum context smaller than the preferred context, but greater than zero) needed to cause scrolling in this instance? Does that need to be user-controllable?
Is being scrolled all the way left “special” — do we avoid scrolling away from hard left in some cases where other rules say we should?
Does context need to clear the dialog, or just found text? (And analogous questions to various ones above if context should clear the dialog.)
If Settings | Preferences… | Editing 1: Enable scrolling beyond the last line is not checked, should it be temporarily enabled (assuming this is possible) if necessary to clear the search dialog?
If the search dialog cannot be cleared, should it be moved?

That’s just what’s occurred to me so far… not yet having tried to implement anything. What do others think? Is there a solution that doesn’t require half a dozen new settings (which would have virtually no chance of approval)?

Marshall-Brooks

@Coises - Great questions! I hadn’t realized how complicated this issue could get and how quickly.

Unfortunately, I think you are going to get different answers depending on how NPP is being used. For that matter, I personally might want different results depending on whether I am editing computer code or prose/text etc. And I don’t think NPP can determine which is which.

9 - I think you basically had this with 8. Put the found content near the top if searching forward and near the bottom if searching backward.
10 - Me personally, 1 line above and one or two lines below the search results.
11 - Me personally, just so there is at least one or two words following the search content.
12 - If you are implementing this, I think yes, you scroll and/or move the dialog to show the desired amount of content.
13 - I wouldn’t say scrolled hard left is special - i.e. I wouldn’t avoid doing it when the rules say it should, but I would minimize it. (Personally, I would probably be okay with scrolling away from hard left if the “Find Next” moved the search back to hard left (if the rules allowed that). I don’t want the the search to scroll over an inch and then stay scrolled over until I manually move the scroll bar back.
14 - I think context needs to clear the dialog. My answers to 9-13 were based on that.
15 - I wasn’t aware NPP has this feature. If line numbers are turned on, I think temporarily enabling it would be a good idea. If line numbers can be turned off, I think you will confuse users. “I thought that was the end of my document, but there are clearly 5 lines beyond my last word.”
16 - Personally, I would like for the dialog to move if needed. That’s what I end up doing manually. (But I’m sure there are some users who are OCD and “I positioned the dialog at 432 pixels from the left and 32 pixels from the top b/c I WANTED it there and now it moved …”).

Thank you for the thought you put into this!

mkupper

@Marshall-Brooks and others:

Some text editors have their find box at the bottom of the screen. It’s always out of the text editing area. Unix’s vi comes to mind but a few editors for Windows also do this.

Notepad++ is tricky in that the dialog box has five tabs, each of those tabs have a similar but not identical set of fields. I’m thinking that if Notepad++ offered a mode where the dialog box one or two lines and locked to the bottom of the screen, never on top of the text area, that it would have the desired result other than auto-scrolling to show the selected area, which I consider to be a separate topic.

Coises

@mkupper said in Find/Replace Window blocking results ...:

Some text editors have their find box at the bottom of the screen.

Notepad++ has Search | Incremental Search. However, it only works for literal searches (not extended or regular expression) and only for finding, not replacing.

I wonder how hard it would be to extend that functionality to support regular expressions and replacements… well, I see there has been discussion. A lot. #8247 • #11902 • survey: Incremental search usefulness and probably more I didn’t find. It looks like they’ve all stalled out, one reason being that the developer of Notepad++ apparently wants to keep that feature very simple: If user wants regexpr, they can use Find dialog.

Also, there is that button with an upward-pointing arrow at the lower right of the Search dialog: it hides most of the dialog, making it easier to get it out of the way. I always forget about that one.

When I think of it, there are multiple potential solutions to the “hidden behind the dialog” part of the problem. Find Next (F3) and Find Previous (Shift+F3) work if you dismiss the Search dialog after the first search — that’s what I usually do if I expect to repeat the same search many times — but there is no corresponding command to Replace without the dialog open. I wonder if there is an opportunity there?

None of this addresses the context feature, though, just the “dialog in the way.”

guy038

Hello, @coises and All,

In order to improve viewing of ALL the different matches of a specific search, we could add, in the Find dialog ONLY, this new option :


❐  Close after find

or


❐  Close after first find

Then, if checked, we’ll continue the search, using the F3 or Shift + F3 shortcuts

For example, this option is present within Notepad2 and Notepad3.

At any time, if we need to open the Find dialog again, we’ll just need to use the Ctrl + F shortcut.

Best Regards,

guy038

Coises

@Marshall-Brooks, @Zack-Wallace, @PeterJones, @mkupper, @guy038 and anyone else interested:

When I coded the Search functions in my Columns++ plugin, I made an attempt to show context.

In the original implementation of Search in Columns++, it was not possible for a match to span multiple lines, because it worked only on column selections and each match had to occur within a single row. Looking at my code (it’s been awhile), it looks like I never changed the positioning code to account for the expansion to contiguous multi-line search regions… so it probably does some dumb things now which I just never noticed. I apparently made these choices:

If the (first) line containing the found text is visible on the screen, don’t scroll vertically.
If the (first) line containing the found text is not visible on the screen, scroll so that it is approximately one-quarter of the total number of lines visible on the screen past the nearest edge.
If after scrolling vertically (if required) the entire found text is visible, don’t scroll horizontally.
If it’s possible to show the entire found text while scrolled all the way to the left, scroll all the way to the left.
If the width of the found text is greater than or equal to the width of the visible area, scroll the end of the found text (the caret) to the far right edge.
If the width of the found text is less than the width of the visible area, scroll so that the margin in the direction preceding the search (left for forward searches, right for backward searches) is the lesser of five times the width of a blank in the default style and half the difference between the widths of the visible area and the found text.
The code does not consider the area blocked by the dialog.

I assume (but do not remember) that I experimented a bit to come up with that, but mostly just made it up. I didn’t feel bad about that for a new (at the time) plugin, but I don’t think it’s good enough for a proposal to change Notepad++ itself.

I’ll have to think more about what I would suggest now for an algorithm, but input from others would be very welcome.