Find sometimes doesn't match properly when typing fast in not so small file (but not big either)

[pintassilgo]

I downloaded the latest release and tested again the Find with Im, the same test when I reported #5471 (typing "mousepad" in my fast typing speed in a 265k chars file). Now there are no missing chars, but there's a little freezing in Cuda before the word appears in find input, and sometimes the find doesn't work properly.

Document has a single match of "mousepad", but sometimes Cuda state is that wrong: current match is "mou" from one "mouse" word (there are many in the document), while find input is "mousepad" and status shows "Found next match (wrapped, edge-cross, from-caret)". If I press F3, Cuda jumps to the correct "mousepad" match. But I shouldn't need to press F3. Find input is "mousepad", so this word in document must already be the match, not "mou".

Results vary when I try to reproduce. It just happened that "Mousepa" is matched, missing the last "d" char as if find input was "mousepa", but it's not, it's "mousepad". Again, if I press F3 it fixes by including the "d" char in the match.

The screenshot below is similar, but the match is "mousep", missing "ad", but Find input is "mousepad" so it's wrong.

[pintassilgo]

The issue is reproducible even with Hi disabled.

Seeing that behavior, I suspect Cuda is not interrupting current find processing when find input changes, but it obviously should. Find should always be interrupted and restarted when input changes.

On this new example, I added a word "mousepa" near the "mousepad" word to see if status would count correctly. Status still shows "[1/1]", which is correct because there is only a single match of "mousepad" string. But what is highlighted is "mousep", and for this string there are two matches.

Conclusion: it seems status is always right, the issue is in jumping and highlighting the string on document.

[Alexey-T]

made test file with line count >4000 (option "find_hi_max_lines":4000, ie default).
repro-find.zip

so timer works for find-dlg-inputting.
do you have repro with it? enter 'mousepad' with 3 matches on the begin.

[Alexey-T]

if my file gives repro, 2nd question: do you see repro (with my file) on clean Cud?

[pintassilgo]

The file I was editing when I detected this issue has 3132 lines, so maybe it isn't good to test with a file higher than find_hi_max_lines. By the way, I use 100000 for this option.

I just tried to run on clean Cuda using latest beta, but it's strange, find is running with timer but it shouldn't. As I said, my file has under 4000 lines and as a clean Cuda I didn't change this option. And there's no giant line to bypass find_hi_max_line_len, the entire file length is below the 800000 default value of this option (I use 100000 in my Cuda).

[Alexey-T]

the reason of this (timer usage) it this: see my new appendix to description which reflects new code:

..............
  //Option is used also here: when document size is bigger than option_value*50,
  //Find-dialog will use timer for 'immediate search' ('Im') option. Ie 'immediate
  //search' will search for a next match 'on timer tick'.
  "find_hi_max_lines": 4000,

[pintassilgo]

I'm not able to reproduce with default Cuda (the only change was "find_hi_max_lines": 6000, to avoid the timer).

I'll keep testing to try to detect what is causing the issue.

[Alexey-T]

If you can repro with some fixed user.json it is OK for me, so do you have repro with "find_hi_max_lines": 6000 with my file, maybe changed file?

[pintassilgo]

Yes, I can repro with clean Cuda with my user.json. I'll try to get a similar file to mine in which I can reproduce the issue.

[pintassilgo]

Sorry for being late, I was about to upload a video yesterday showing the issue when power went off in my neighborhood and that broke my PSU so I was without my computer. I'll have to redo everything because the video was saved in tmp, which is erased when the computer turns off.

[pintassilgo]

It's not easy to reproduce. Look at the video below. You see I try to reproduce by typing fast "mousepad" multiple times. It was working as expected many times. But at the end you see only "mou" is highlighted (from a "mouse" word). I should have manually scrolled to the "mousepad" word instead of clicking "Find next", then you would have seen that only "mou" was highlighted, even if find input is "mousepad".

a.mp4

[Alexey-T]

So the search is run by timer? or immediately?

[pintassilgo]

Immediately. But sometimes it misses my fast typing, stopping at the middle of the word. In the example shown in the video, you see me typing "mousepad", but find stops at "mou". It should be possible to improve code to prevent that, interrupting current processing of searching for matches immediately when find input changes, then starting to process using new find value.

[Alexey-T]

can you 'mask the file' by replacing RegEx \w with 'a' and then typing 'mousepad' in several places? share the file then.

or: send me the file to email support(at)uvviewsoft.com

[pintassilgo]

I can do that, but I fear you would just say you can't reproduce and dismiss because of that. Even I find hard to reproduce the issue, sometimes I need to type exhaustively the word many many times until I catch the issue.

So unless you can do special debug from that, I guess it's better to just believe me (or believe in the video).

It's also needed to type very very fast... it's a hard task to reproduce it. But still it's an issue.

[Alexey-T]

I made small change and updated the beta. not sure it's ok.

[pintassilgo]

Gtk beta: doesn't have the grey issue,

It has, however, a bug of stuck progress bar:

This screenshot was taken many seconds after I typed in find. It's no longer processing anything, it's already done. But process bar is still displayed and, worse, showing 5%.

It's similar to the initial issue here in the matter that it's a bit hard to reproduce the issue, needs to type very fast in big file and even then it's needed to try a bunch of times until you see.

[pintassilgo]

This progress bar thing is a bug of new beta, Qt5 is also affected. The previous beta 57 I use in my main Cuda doesn't have stuck progress bar, it was a regression from a change you made yesterday.

[pintassilgo]

Despite this stuck progress bar, which affects both Qt5 and Gtk latest beta, the Gtk version doesn't blink progress bar many times while I'm typing fast in find, unlike Qt5.

Something in the Qt5 version calls the progressbar to be displayed every new char I type.

But this is maybe for another time. Current main issue is I have to choose between beta 57 which has this #5473 bug or the latest beta that I can't even test this bug because the gray issue makes any find usage/test useless. In fact, the latest beta with gray issue doesn't select the word in Qt5 version, which is a worse version of this bug, because in beta 57 it only misses some chars, while beta 58 doesn't select anything as you can see in my most recent video in previous comment.

As it stand, while it isn't fixed, beta 57 is still my best choice, I'd say 732b37d made things worse for me (supposing this was the change that caused the gray bug).

[pintassilgo]

(offtopic: replace-all for regex \w takes 1 minute for file 'torrent.cpp' , size is 400k.)

I just confirmed this is another case of the difference between Qt5 and Gtk Cuda. For some reason, Gtk is much much faster to replace, at least using regex. Qt6 Flatpak Cuda is also slow.

[pintassilgo]

Forget what I said about regex. I'm doing new tests and will probably open a new issue. It's not related to difference between Qt5 and Gtk.

[Alexey-T]

Updated 2 betas again: gray must be not fixed, but progressbar flickering must be better.

[pintassilgo]

I don't see difference with new betas. Same results.

• Gtk: still no progressbar flickering
• Qt5: still the same flickering as previous beta, and also still discarded by me because of the gray issue.

[Alexey-T]

So I will test this more on 2nd PC, and only if I repro gray effect (it has newer Ubuntu) I will try to fix it.
If I won't repro gray effect, we are stuck.

[pintassilgo]

More info on this topic. I reproduced that issue in a different and better way, without Hi and without HiOccur. Only Im is required. Sorry for the long read ahead, but it's needed.

It's a giant 13GB text file with 340 million lines of 60 chars in each one. By the way, is there a command to count lines in giant files? What I did was running Ctrl+G ("go to line" command) multiple times with increasing numbers until it reaches the end of the file, then I can estimate the total, but I don't know if Ctrl+G is reliable in giant files.

Back to the issue, each line has a unique increasing integer composed by 11 digits. So I pressed Ctrl+F and typed a 11 digits number. When Cuda found the number and selected it, progress indicator restarted to 0%, and this repeated 2 more times without me doing anything, I was only looking at the screen. At the end, when progress finally disappeared from status bar, Cuda selected a different string in document, similar but different to the number I had typed in find.

Next I done everything again, with a single difference: I waited more than one second between each new char I typed.

Up to typing the 6th char, Cuda was able to jump to next match instantly
7th char wasn't instant, but it was fast enough to finish before I typed the next char.
From 8th to the end (11 chars in total), Cuda couldn't finish in time, so for each new char I typed I could see progress bar resetting to 0%.

The number I was searching was near the center of the document, it was found when progress showed 41%. When it was found, Cuda should have finished find work, but it didn't, and that's the bug that must be fixed. Instead of stop processing and hiding progress bar, it restarted from 0%. It increased up to 41%, then restarted again. Then, one more time: 41% and restart. While I watched this, my number was still correctly selected on document even after the progress restarts, nothing changed in this regard. But finally, a couple of seconds after the third progress restart, progress disappeared because Cuda finished the work, but when this happened it jumped to other part of document, selecting a different string.

Suppose my find input was 98765432109. This string was found and selected when progress reached 41% for the first time. But when Cuda finally finished processing after all the restarts, it jumped and selected a slightly different string: 9876543278|. You see the first 8 chars are identical to what I typed in find input, but the last 3 chars are different. Notice the size of the string is still the same (11 chars).

Clearly, the issue is that Cuda stacked 4 unfinished find commands while I typed. This shouldn't have happened. When Cuda detects find input changed, it should interrupt current processing and run find command for the updated string.

[pintassilgo]

Video showing me doing what I said in previous comment. In the video, match didn't change at the end, but the important thing is: at 01:03 in the video, when progress was at 41%, Cuda finds what I had typed in findbar, it should had finished at that moment, there's nothing more to be done. But the progress restarts and Cuda keeps processing find till the last seconds of the video even if I did nothing, the last char I typed was at 00:21.

Note: there's a glitch in find input that couldn't display the last chars while Cuda was busy processing the find. This glitch gets fixed at 01:03 when Cuda finishes the first find processing (and should have finished everything at this point because it already found the match for the entire find string, but it restarts processing find and this is the bug that needs to be fixed).

One more thing to note is "Cancel" button is only visible before the first restart. After this, there's no way to cancel. This could be a key for you to find where in the Cuda source is the issue.

f.mp4

[Alexey-T]

converted the topic to 'discussion'.

[pintassilgo]

I don't know your purpose in closing open issues. I understand that you don't know how to fix it now, but it's still a bug, so it should remain as an open issue, that's what it is. It's not a discussion, it's an issue.

[Alexey-T]

you are right! converted back to 'issue' but new issue was created for it now.

[Alexey-T]

yes I see the problem (in different way: I do search for 9876543 in 500Mb log). it can be worked around by

"find_hi_timer_lines":9999999

log is made by this script:

f = open('/home/user/log', 'w')
for i in range(1000*1000*50):
    f.write('line '+str(i)+'\n')

but it's not ok solution. yes we need to break the previous long search when new char is typed.

[Alexey-T]

issue was fully fixed day ago. closing.