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