Notepad++ fails to jump to search hits initiated by "Find All in" (Current Document/All Opened Documents) searches for the first, new, unsaved document under certain conditions.

[xEBFE]

Description of the Issue

Notepad++ fails to jump to search hits initiated by "Find All in" (Current Document/All Opened Documents) searches for the first, new, unsaved document under certain conditions.

The two conditions:

• A saved document must be opened by NP++ at some point.
• A "Find All in" (Current Document/All Opened Documents) search for any search term must be initiated at some point.

After these two condtions are met:

• The first new, unsaved document that is created anytime after a saved document is opened in NP++ will be ignored by any double-clicking (jump to behavior) of search results for any subsequent "Find All in" (Current Document/All Opened Documents) searches.

Steps to Reproduce the Issue

1. Open Notepad++ ensuring that there are no open documents other than the default "new 1".
2. File > Open... "needles in the haystack.txt" and select "Open".
3. Search > Find... "needle" (without quotes and Search Mode = Normal) and select "Find All in Current Document".

The Search results window will show a listing of 5 hits (1 file).

4. Double-click any of the hits from the Search results window and NP++ jumps to the location of the result within the document. This is expected behavior.
5. Edit > Select All (Ctrl+A) from the content of the "needles in the haystack.txt" document.
6. Edit > Copy (Ctrl+C or Ctrl+INS).
7. File > New (Ctrl+N). A new document tab, "new 1", appears.
8. Edit > Paste (Ctrl+V or Shift+INS) into "new 1". Now the content from "needles in the haystack.txt" is duplicated into this new, unsaved document "new 1".
9. With the Search results window still up, right-click and select "Clear all".
10. Search > Find... "needle" (without quotes and Search Mode = Normal) and select "Find All in All Opened Documents".

The Search results window will show a listing of 10 hits (2 files).

11. Double-click any of the hits from the Search results window and NP++ jumps to the location of the result within "needles in the haystack.txt" but double-clicking any of the hits from "new 1" will fail to even activate the view of the document and/or jump to the location. This is unexpected behavior.

Addendum:
If you repeat steps 7 and 8 several times for further new documents ("new 2", "new 3", "new 4") then proceed with steps 9 through 11. The behavior of jumping to the correct location works for all of the documents except for the first, new, unsaved document created after our opened document ("new 1" in our example).

Expected Behavior

Double-clicking any of the hits from the Search results window will result in NP++ jumping to the correct doucment and line of the search hit.

Actual Behavior

Double-clicking any of the hits from the Search results window will result in NP++ jumping to the correct doucment and line of the search hit with the exception of the first, new, unsaved document created after opening a saved document.

Debug Information

Notepad++ v8.5.2 (64-bit)
Build time : Apr 4 2023 - 19:55:32
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 7 Professional (64-bit)
OS Build : 7601.0
Current ANSI codepage : 1252

UPDATE: This bug seems to have been introduced in Notepad++ v8.5 as the last verison to exhibit expected behavior was in Notepad++ v8.4.9.

[alankilborn]

@Yaron10

Here's some STR for this, that I couldn't quite come up with myself in another issue.
In theory, this bug had been fixed before -- but it won't stay dead. :-)

[Yaron10]

@alankilborn,

Yes, I remembered #13608 (comment).
I assumed you'd see this thread. :)

[molsonkiko]

Can confirm. Also wanted to elaborate that changing the display name of the first unsaved document will make it so that that document is no longer missed.
To test:

1. Open a saved file containing any word (your choice)
2. Open a new file (new 1) and type that word
3. Ctrl+F for that word
4. Open another new file (new 2 probably) and type that word
5. Open new 3 and type that word.
6. Ctrl+F for the word. As OP demonstrated, it can be found in new 1 and the originally saved file and new 3, but not in new 2.
7. Change the displayed name for new 2 to new 2.foenreo
8. Ctrl+F for the word. Now it can be found in new 2.foenreo.

[alankilborn]

changing the display name of the first unsaved document will make it so that that document is no longer missed

That's a nice workaround--thanks!

[Yaron10]

UPDATE: This bug seems to have been introduced in Notepad++ v8.5 as the last verison to exhibit expected behavior was in Notepad++ v8.4.9.

I've just seen that. Interesting.

[white-gthb]

I also confirm the bug since version 8.5. I use these simplified steps to reproduce:

Steps to Reproduce the Issue

1. Open Notepad++ ensuring that there are no open documents other than the default "new 1".
2. File Open... "needles in the haystack.txt" and select "Open".
3. Search Find... "needle" (without quotes and Search Mode = Normal) and select "Find All in Current Document".
4. Edit Select All (Ctrl+A) from the content of the "needles in the haystack.txt" document.
5. Edit Copy (Ctrl+C or Ctrl+INS).
6. File New (Ctrl+N). A new document tab, "new 1", appears.
7. Edit Paste (Ctrl+V or Shift+INS) into "new 1". Now the content from "needles in the haystack.txt" is duplicated into this new, unsaved document "new 1".
8. Search Find... "needle" (without quotes and Search Mode = Normal) and select "Find All in Current Document".
9. Double-clicking any of the hits from "new 1" will fail to jump to the location of the result.

[alankilborn]

Sadly, this issue hasn't gotten much traction, although it is easy to reproduce and clearly a problem. :-(

An obvious and easy workaround is to NOT do this type of searching in a new x tab.

[molsonkiko]

I'm going to look over these commits to see what might have caused this bug. If others want to do the same, that would help.

[alankilborn]

I'm going to look over these commits to see what might have caused this bug. If others want to do the same, that would help.

From the tone of that comment, it seems like you feel this is a "tough one". :-(

[jofon]

@molsonkiko
See commit 892ab08
After opening the needles txt, place a breakpoint in that function (FileManager::nextUntitledNewNumber()), and follow the rest of the steps.
Before the commit: two stops on that function, returns 1 for the search results window, and returns 2 for the new empty document.
After the commit: two stops on that function, returns 1 for the search results window, and returns 1 for the new empty document.

Didn't look into it more, but I guess it won't consider the new document correctly due to the number already being used or something.

[molsonkiko]

@jofon

Yep, good catch!

It seems like there's some relevant discussion in #8677, which is one of the issues closed by that commit.

An executive summary of the conversation:

• some docking forms, including the search results dialog that is at issue here, have buffers created when they are made
• these new form-related buffers are also numbered according to the new N system
• prior to this commit the form-related buffers counted towards the used numbers for new N files
• that was confusing, because the user doesn't think of them as buffers but they cause the number for "real" buffers to "jump" from N - 1 to N + 1

I think it would be a bad idea to try changing how that commit worked, because it would likely cause all sorts of problems completely unrelated to the very simple problem we are trying to solve here.

AFAIK none of these other forms cause issues with the search results form. I think the problem is that, when you click on the search results form, the currently active buffer is new i, which is associated with the search results form itself. Thus, Notepad++ correctly identifies that new i is already open when you click on a row associated with the "real buffer" new i in the search results form.

[molsonkiko]

Inspired by jofon's analysis and my investigation of the related issues, I discovered that the Document Map (not to be confused with Document List) causes the same problem.

To duplicate:

1. open a file with some text
2. open document map
3. open a new 1, paste contents of first file into it
4. Find all in current documents, observe that new 1 can't be jumped to
5. Open a new 2, paste in contents of first file
6. find all in current documents, observe that neither new 1 nor new 2 can be jumped to because both names are shadowed, one by the search results buffer and one by the document map.