"Find All..." does not work right with long lines

[AndiKiissel]

Description of the Issue

"Find All..." does not show all findings in long lines

Steps to Reproduce the Issue

1. Unpack 64bit (or 32bit) Portable Minimalist Notepad++ v8.4.4 in new folder
2. Open this testfile _long_line_test.txt
3. Find...
4. Find what: a
5. Find All in Current Document

6. Try to catch all "a"-s

Expected Behavior

All "a"-s found, unindependent of line length

Actual Behavior

"a"-s not found after Col:~2048

Before v8.4.3 all "a"-s could be found with F4 / Shift-F4, but not now.

Debug Information

Notepad++ v8.4.4 (64-bit)
Build time : Jul 15 2022 - 17:54:42
Path : F:\NppTest64\notepad++.exe
Command Line : F:\NppTest64_long_line_test.txt
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 21H2
OS Build : 19044.1889
Current ANSI codepage : 1257
Plugins : none

[alankilborn]

Good bug report.
Reproducible with instructions as provided.

Additional suggestion for easier reproduction, because there are so many matches in the sample text file, add this to step 6:

• With focus in the Search results window, hold down F4 so that it repeats. When the screen stops updating, release F4 and then note what column you are in in the source file (it will be 2050), and note that if you horizontally scroll right in the source a little bit you should see the next a (or A) that F4 should have jumped you to (in column 2081).

This is a new (bad) effect from the 8.4.3+ new feature where multiple matches per line are shown in a single line of Search results output. BUT...turning the new feature off so that there is one line of output for each match still results in the same problem with F4 (double-clicking a line in Search results works correctly for all matches, though).

[alankilborn]

"a"-s not found after Col:~2048

This is interesting as SC_SEARCHRESULT_LINEBUFFERMAXLENGTH in the code is set to 2048. Basically, the effect of using that number is that ... appears on the far right in the Search results if a source line with hit(s) is longer than that.

But, I found a case where F4 moves the caret in the source file to a hit in a column much greater than 2048 -- but in the Search results the hit isn't shown because the ... is there.

Search _long_line_test2.txt and do FACD on Z to experiment with this. I put a Z in columns 1000, 2000 and 3000.

_long_line_test2.txt

[AndiKiissel]

Yes, it behaves variously and it's difficult to describe all possible ways.

Switch OFF "show only one entry per found line"
In _long_line_test.txt Find All... a
Shift-F4 - right place! (last match)
Shift-F4 - again right place (2nd from end)
F4 - nothing happens!
Shift-F4 - right place (3rd from end)
F4 - nothing...
So, this way Shift-F4 works, F4 not.

BTW, with 2-byte UTF-8 alphabets things go bad from ~1024 characters.

I'd like to say, that Find All.. behaviour with long lines is unpredictable and unreliable.

[alankilborn]

I'd like to say, that Find All.. behaviour with long lines is unpredictable and unreliable.

@AndiKiissel I suppose some of the problems you were trying to get attention on in #11808 are now coming back to haunt the development team as regressions in released software. :-(

BTW, with 2-byte UTF-8 alphabets things go bad from ~1024 characters.

This makes some sense because the history of Notepad++ and Scintilla came from the times of "1 character = 1 byte", and the data buffers that they use are defined in terms of bytes. So if you had a long line made up of exclusively 4-byte UTF-8 characters, things would "go bad" at around 512 characters. :-(

[AndiKiissel]

Unfortunately, "Find..." bugs are insidious because the user may not know that something was not found and/or seen. And this can be costly - in time, in reputation, in money. :-(

[Yaron10]

@AndiKiissel,

The main issue is a good catch. 👍

@donho,

Could you please look into that?

---

@AndiKiissel,

Regarding F4:

#11808 (comment)
I'd suggest opening a separate issue.

[alankilborn]

@Yaron10 said:

Regarding F4
I'd suggest opening a separate issue.

It seems that ALL of the problems are related to working with F4 or Shift+F4.
But if several issues helps get attention, then why not...

[Yaron10]

@alankilborn,

It seems that ALL of the problems are related to working with F4 or Shift+F4.

I don't understand it.
The main/first issue here is about matches after 2048-chars not being displayed.

What do you think about displaying the entire line without truncating?
Would that require changing the Scintilla code as well?

[alankilborn]

The main/first issue here is about matches after 2048-chars not being displayed.

My interpretation was that even if the matching text isn't shown in Search results (because it is in the ... region), F4 should still jump to it -- and it doesn't.

Turning off the new single line output feature allows you to double-click a line in Search results and jump to the correct match, but even it isn't working correctly any longer -- it jumps to the match, but match-highlighting in Search results is wacky.

Example, using OP's original file and STR (except turn off the new single-line output feature): Start at the bottom of the Search results output and double-click each line in turn, moving up one line each time. Note that the correct match in the source is jumped to, but the selected text in Search results is NOT the hit text for that line, but is usually TWO full lines.

So...in summary...MANY PROBLEMS here, not sure how to nail them all down. :-(

[alankilborn]

What do you think about displaying the entire line without truncating?
Would that require changing the Scintilla code as well?

I'm not sure of the technical limitations here, but I presume the ... stuff was added because there was some limitation (otherwise, why go to the trouble and introduce a limit).

I know that the limit was originally 1024 but was increased to 2048 in the last few years.

SC_SEARCHRESULT_LINEBUFFERMAXLENGTH is set to 2048 in scintilla.h, so I suppose Scintilla code needs it for some reason (didn't look).

What do you think about displaying the entire line without truncating?

I certainly like the idea of it.

[Yaron10]

@alankilborn,

@AndiKiissel did mention in his first post here both "not displayed in long line" and "F4/Shift+F4".
But the "F4/Shift+F4" issues are not specific to long lines. That's why i suggested to create a separate issue for that.

Example, using OP's original file and STR (except turn off the new single-line output feature): Start at the bottom of the Search results output and double-click each line in turn, moving up one line each time. Note that the correct match in the source is jumped to, but the selected text in Search results is NOT the hit text for that line, but is usually TWO full lines.

That's another good catch. 👍

So...in summary...MANY PROBLEMS here, not sure how to nail them all down.

1. Long lines - current issue.
2. Long lines - selection glitch (your catch, would you open a new issue?).
3. "F4/Shift+F4" issues.
4. Suggestion: Search in All Documents -> show how times there is corresponding results in same line #12010 (a nice and useful enhancement).

If @ArkadiuszMichalski could tag them all Multiple Matches in One Line, it would be helpful and appreciated.

---

I'm not sure of the technical limitations here, but I presume the ... stuff was added because there was some limitation (otherwise, why go to the trouble and introduce a limit).
...
I certainly like the idea of it.

Thank you.

Let's wait for Don.

[alankilborn]

@Yaron10 said:

2. Long lines - selection glitch (your catch, would you open a new issue?).

Done, in issue 12024.

[Yaron10]

@alankilborn,

👍
Thank you.

[Yaron10]

@donho,

Is the long-lines issue complex to fix? Would you label it as "won't fix"?
You did a great job on this feature and it would be a shame to "tarnish" it with that issue. :)

Thank you.

[donho]

@Yaron10
Thank you for reminding Ping.

Do you guys think really #12014 is the solution of this issue?

[Yaron10]

@donho,

Obviously the best solution would be fixing the issue(s). At least those which are not "enhancement".
If it's too complex and the question is about the default setting - I don't know.

Thanks again for your work and for looking into it.

[alankilborn]

F4 still won't advance beyond column 2050, see old comment #12023 (comment)

[AndiKiissel]

Yes, Shift-F4 works as it should, F4 doesn't.

[alankilborn]

Note that v8.6.1RC1 fixes my STR here: #12023 (comment) using the file I provided at that link.

But... I noticed that while Shift+F4 will "wrap around" in the search-results, F4 will not "wrap" (i.e., once the final match is located, pressing F4 has no effect). It should wrap.

[alankilborn]

Also in v8.6.1RC1, with the original STR of this issue, after F4 refuses to continue finding matches (do the search, then hold down F4 until things stop changing), the UI is left in this strange way:

The second Line 1 line in the results has "current line" background coloring (which may be correct for the match it should be on), but why does the third Line 1 line have a grey background color for its first portion?

[donho]

@AndiKiissel & @alankilborn
Could you check #14544 please?

[AndiKiissel]

Yes, the F4 bug with long lines is now fixed. Thank you!

[alankilborn]

@donho said:

AndiKiissel & alankilborn
Could you check 14544 please?
...
closed as completed in 9c7bb8a

If you're going to ask people to check something, suggest you actually give them a reasonable amount of time to do it in.

Bug notification time to fix time: 6 days (29 Dec - 3 Jan)
Time from request-to-check to unchecked-acceptance: 7 hours

I had intention to do a good job of checking it, but I hadn't had time to yet.
I won't bother to check it now, as it is accepted and original-petitioner likes the fix.

---

Overall, however:
Thank you for the fix!
It will be good to be able to trust Notepad++ again when I'm working with searching very long lines!!

[donho]

@alankilborn

If you're going to ask people to check something, suggest you actually give them a reasonable amount of time to do it in.

Bug notification time to fix time: 6 days (29 Dec - 3 Jan) Time from request-to-check to unchecked-acceptance: 7 hours

Oups, sorry - I'm currently in holidays (out of France), so the time for working on the project (with the clear mind) is much less. Just tried to get any rare chance to make progress to get release done.

BTW, happy new year!

[alankilborn]

BTW, happy new year!

Indeed, yes, let's clear out the old and bring in the new! :-)

---

Also, on the earlier point, everyone should keep in mind that if you expect a quick response on something, you might miss someone by virtue of their sleep cycle times (or just end-of-day AFK times) in world-wide development. This is obvious, but I sometimes forget. :-(

Example: donho(Paris) <-> alankilborn(Detroit) == 6 hour time delta (not terrible, could be worse for some others)

Thankfully we don't often need really fast reaction times to things.

[donho]

@alankilborn
ha! I passed by Toranto last summer - we could grab a beer together...
But maybe next time.