Re: Filtering also matches the filenames...

> in the attached screenshot kate-rtes.png the filter text is "rtes", and
> although this is not anywhere visible in the results, they all are accepted by
> the filter. To me this looks clearly like a bug.
> They are accepted because they are all somewhere below ...src/dockertest/
> (which contains "rtes").

Correct.

> When I remove the search base directory for the filtering, it works better,
> but leads to the result as in kate-sub.png.
> The filter is "sub", and all matches are displayed, since they are all in the
> "sub/" directory, which is visible in the names of the file items.
> But the number of matches is completely wrong then. The number of matches
> counts how often the search time was found, and since none of the actual text
> matches matches the filter, it is zero.
> If the filtering would only test the actual content, I think this issue would
> go away.

Yes, but it removes a feature so imo not a good idea. Directory/file
filtering was one of the main reasons I added this feature :)

One big reason I didn't bother with updated row count was because this
filter is temporary and not something you should rely on to find out
how many matches there are *after* the filtering. The point is to be
able to focus on a part of the search, hence updated rowCount for me
is not useful at all.

On Tue, Mar 8, 2022 at 1:54 PM Alexander Neundorf <[email protected]> wrote:
>
> On Montag, 7. März 2022 20:06:27 CET Waqar Ahmed wrote:
> > Also, I think using a single character for filtering is just unrealistic,
> > and using it to test the filter quality is imo not useful. With a few more
> > characters or a word, the filter will work better.
>
> in the attached screenshot kate-rtes.png the filter text is "rtes", and
> although this is not anywhere visible in the results, they all are accepted by
> the filter. To me this looks clearly like a bug.
> They are accepted because they are all somewhere below ...src/dockertest/
> (which contains "rtes").
>
> When I remove the search base directory for the filtering, it works better,
> but leads to the result as in kate-sub.png.
> The filter is "sub", and all matches are displayed, since they are all in the
> "sub/" directory, which is visible in the names of the file items.
> But the number of matches is completely wrong then. The number of matches
> counts how often the search time was found, and since none of the actual text
> matches matches the filter, it is zero.
> If the filtering would only test the actual content, I think this issue would
> go away.
>
> Alex