[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Filtering also matches the filenames...
From:       Waqar Ahmed <waqar.17a () gmail ! com>
Date:       2022-03-08 9:05:21
Message-ID: CAPesRH7r4DeGJiiQZ2n3Yzt=Z7SR5ZTns=TmUc_T+7QCHbNmrw () mail ! gmail ! com
[Download RAW message or body]

> 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 accept=
ed 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 bette=
r,
> 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 w=
ould
> 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 <neundorf@kde.org> wrote:
>
> On Montag, 7. M=C3=A4rz 2022 20:06:27 CET Waqar Ahmed wrote:
> > Also, I think using a single character for filtering is just unrealisti=
c,
> > and using it to test the filter quality is imo not useful. With a few m=
ore
> > 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 accept=
ed 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 bette=
r,
> 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 w=
ould
> go away.
>
> Alex
[prev in list] [next in list] [prev in thread] [next in thread]