Re: Filtering also matches the filenames...

On tisdag 8 mars 2022 11:05:21 EET Waqar Ahmed wrote:
> > 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.
> 

I think we could at least ignore the common folder path when doing the filtering.

I think it is a bit un-intuitive to not have the match/checked count updated properly...

I think we should do the move of the checked/match count to the proxy/delegate even if it 
is a bit more work and it could get a bit slower if we have thousands of matches/files. I 
think I can have a look at it, that is if Alex does not want to do it ;)

Regards,
  Kåre 


> 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