FindAll with single zero-length match at start-of-file breaks subsequent same search

[alankilborn]

Description of the Issue

For more info/discussion, see https://community.notepad-plus-plus.org/topic/25591

Steps to Reproduce the Issue

1. Extract and run a fresh 8.6.4 portable version
2. Type f into the new 1 tab
3. Press Ctrl+f to invoke Find
4. Set Find what to \A and choose Regular expression for the Search mode (all other checkboxes to be uncheckmarked)
5. Press the Find All in Current Document button
6. Observe "1 hit" in Search results window
7. Repeat steps 3 through 5

Expected Behavior

I expected to see "1 hit" again in Search results window.

Actual Behavior

I saw "0 hits":

Debug Information

Notepad++ v8.6.4 (64-bit)
Build time : Feb 20 2024 - 00:12:59
Path : C:\NotepadPlusPlus\Misc_NoBackup\Releases\npp.8.6.4\npp.8.6.4.portable.x64\notepad++.exe
Command Line : -multiInst
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 11 Pro (64-bit)
OS Version : 23H2
OS Build : 22631.3155
Current ANSI codepage : 1252
Plugins :
mimeTools (3.1)
NppConverter (4.6)
NppExport (0.4)

[molsonkiko]

I can replicate this with the current master. Plugins don't matter, nor does the -nosession flag.

This actually isn't the first time I ran into an issue like this; a while back I tried to make it possible to count all empty matches using the Count command in the Find tab of the find/replace dialog, and it worked fine the first time I ran the operation, and then it didn't count empty matches on subsequent runs.

[molsonkiko]

This is only a problem when there is only one empty match, and if you do another search in between that matches anywhere else in the document, you can do one more search for \A before the problem recurs.

EDIT: Never mind, this is only a problem with zero-length matches at the start of the file, like AlanKilborn originally said.

For example, if you have the document

foo
bar

you can alternate searching for ^(?=f) and ^(?=b) and never get weird behavior, but if you do one of those searches twice in a row, the second search will fail. EDIT: only consecutive searches for ^(?=f) fail, because that is at start of file.

I also notice that the Find all and Replace all operations use the SCFIND_REGEXP_EMPTYMATCH_NOTAFTERMATCH regex flag to decide whether to accept empty matches.

So here's what I think is happening:

1. the first time you do a search, the finder remembers that the final match of the last search ended at location X and whether it was empty
2. the first match of the next search would also match at location X and be empty, but it fails because of the SCFIND_REGEXP_EMPTYMATCH_NOTAFTERMATCH flag