Find results linking failure related to unicode characters above U+07FF

[Graham-G]

Duplicate?

There are currently 206 open issues related to "find in files". While I have done a cursory search, this may well be a duplicate. Even if it is, the level of detail in bug isolation will hopefully make up for it.

Description of the Issue

Search > Find in files... find result links don't open on double click for a the target file if the found string is preceded by a character in above U+07FF* on the same line AND the last character of the search string is preceded by >= 1010 characters.

* Annoyingly, some parts of the bug appear to actually be based on the directory tree containing the files in question; renaming a folder from testfiles2 to testfiles3 made more results fail in higher test codes; I may investigate this further.

Some other observations: the target string is red in the preview even if only part of it is present, and is only highlighted yellow when the last character is preceded by < 1010 characters. Additionally, the target string is entirely visible when preceded by exactly 1010 characters, but doesn't get highlighted. Being highlighted correlates with being properly linked.

Steps to Reproduce the Issue

1. Open the find in files dialog (using Search > Find in Files... or keyboard shortcut)
2. Extract the testfiles (next section) into a directory
3. Set Find what: to a
4. Set Directory: to the testfiles directory.
5. Set Filters: to *.*
6. Click Find All
7. Try double clicking on the found files in the Find result panel; the first three will fail to do anything upon double click, but the last two will link correctly to the target string in the file.

Testfiles

To demonstrate this, I made some testfiles. In these testfiles, the period (.) was chosen to represent an arbitrary filler character, but it could be replaced by other characters (the bug was originally found when browsing a paragraph of an HTML file, for context; the underscores were added afterwards to isolate the bug.) "—" was chosen as the failure characters, but other characters above U+7FFF; the limit is unclear and inconsistent based on the file directory's name. "Result" indicates whether the results list link worked.

Number	Result	Comments
1.0	FAILURE	Minimum preceding characters; "—" left
1.1	FAILURE	Minimum preceding characters; "—" centered
1.2	FAILURE	Minimum preceding characters; "—" right
2	SUCCESS	Too few preceding characters
3	SUCCESS	Missing "—"

Debug Information

Notepad++ v7.5.8 (32-bit)
Build time : Jul 23 2018 - 02:03:53
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 8.1 (64-bit)
Plugins : ComparePlugin.dll PluginManager.dll DSpellCheck.dll mimeTools.dll NppConverter.dll NppExport.dll

(Plugins were disabled as part of testing.)

[Rainald62]

Good job. The bug is still present, v7.8.2 (64-bit) on Win 10.
Additional observation: In the result list, the pathnames of the files are usually preceded with a "minus sign in square" symbol to hide the following preview lines for any hit. For problematic hits in the sense of this bug, the symbol is missing. In the attachment, this is with two files, Kap. 8.txt and Kap. 17.txt. The search string is "würde", found at col 1121 and 735* respectively.
*) The reported lower limit of 1010 preceeding characters is obviously not meant per line but per file (2310 in this case).