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

List:       kwrite-devel
Subject:    Re: Filtering also matches the filenames...
From:       Dominik Haumann <dhaumann () gmail ! com>
Date:       2022-03-07 21:30:42
Message-ID: CALi_srBG0uuw1FSahSm0r8gW-ZjQxXK9hB=iij_KwgFLyj70ag () mail ! gmail ! com
[Download RAW message or body]

You could do the zoomin only if you type a / as well. It's a bit hidden,
though.

Best regards
Dominik

Waqar Ahmed <waqar.17a@gmail.com> schrieb am Mo., 7. M=C3=A4rz 2022, 20:06:

> 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 mor=
e
> characters or a word, the filter will work better.
>
> On Mon, Mar 7, 2022, 11:29 PM Alexander Neundorf <neundorf@kde.org> wrote=
:
>
>> Hi,
>>
>> the filtering currently also matches the filenames, and that using their
>> full
>> path.
>> This leads to strange behaviour.
>> I typed "x" in the filter, and everything was still visible, although
>> there
>> was no "x" anywhere.
>> I found that the filter "x" matched them all because they were all in
>> some
>> subdir of my home directory "/home/alex/", which contains an "x".
>> In my local copy I changed it so that fileToPlainText() removes the base
>> directory from the filtering, so that only that part of the filename is
>> matched that is also displayed in the results.
>>
>> But that still is strange. If I now enter something that occurs in all
>> found
>> filenames, but not in any actual match, the results list now tells me
>> "0 matched (0 checked)" but still displays all search results and all of
>> them
>> are checked.
>>
>> How about applying the filtering only to the actual contents of the
>> files, and
>> ignore the filenames completely ?
>>
>> Alex
>>
>>
>>
>>

[Attachment #3 (text/html)]

<div dir="auto">You could do the zoomin only if you type a / as well. It&#39;s a bit \
hidden, though.<div dir="auto"><br></div><div dir="auto">Best regards</div><div \
dir="auto">Dominik</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Waqar Ahmed &lt;<a \
href="mailto:waqar.17a@gmail.com">waqar.17a@gmail.com</a>&gt; schrieb am Mo., 7. \
März 2022, 20:06:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, \
Mar 7, 2022, 11:29 PM Alexander Neundorf &lt;<a href="mailto:neundorf@kde.org" \
target="_blank" rel="noreferrer">neundorf@kde.org</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br> <br>
the filtering currently also matches the filenames, and that using their full <br>
path.<br>
This leads to strange behaviour.<br>
I typed &quot;x&quot; in the filter, and everything was still visible, although there \
<br> was no &quot;x&quot; anywhere.<br>
I found that the filter &quot;x&quot; matched them all because they were all in some \
<br> subdir of my home directory &quot;/home/alex/&quot;, which contains an \
&quot;x&quot;.<br> In my local copy I changed it so that fileToPlainText() removes \
the base <br> directory from the filtering, so that only that part of the filename is \
<br> matched that is also displayed in the results.<br>
<br>
But that still is strange. If I now enter something that occurs in all found <br>
filenames, but not in any actual match, the results list now tells me<br>
&quot;0 matched (0 checked)&quot; but still displays all search results and all of \
them <br> are checked.<br>
<br>
How about applying the filtering only to the actual contents of the files, and <br>
ignore the filenames completely ?<br>
<br>
Alex<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>



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