Wrong number of matches found for IN / OUT filter when TEXT file is detected as LOG #1639
Description
lnav version
Compiled from main as of March 3 2026.
Describe the bug
To Reproduce
I have a text file which is recognized as a log because at some point (line < 200) there is an entry which correctly matches a timestamp definition. Not really a problem the file "should" be treated like TEXT instead of LOG (and I don't question how "lnav" does this).
I have a simple string match (stor2rrd) which occurs in exactly 200 different lines in the log (some lines match the string more than once :
$ grep stor2rrd input-file.txt | wc -l
200When opening "input-file.txt" using "lnav", file is processed as LOG (ⓘ info
699D
: syslog_log matched line 186), that's fine. If I search (/) for "stor2rrd", I get 200 hits for “stor2rrd” returned. This is correct (as long as "lnav" is returning the number of lines matched rather than the number of string matches found).
However, when I add an IN or OUT filter, I get this (and that amount of lines in indeed still shown in the TUI) :
◆ IN 39,628 hits │ stor2rrd"input-file.txt" is 40626 lines long including those which are an empty line, and 39015 ignoring empty lines. There are 211 individual "stor2rrd" matches across the file.
If I remove the linue 186 which made the file be handled as LOG instead of TEXT, and load up the file using "lnav" again, the file is now detected as TEXT, then both searching and using IN / OUT filters for the same string return the correct amount of matched lines (200).
I can't immediately share the input file as-is, as it has some customer details, but if you need some I will try anonymizing and trimming it so that a smaller version where the issue still can be seen may be attached to this issue later.