Bug 387618

Summary: words less than 3 letters are ignored
Product: [Applications] kmail2 Reporter: davidblunkett <dav1dblunk3tt>
Component: searchAssignee: kdepim bugs <kdepim-bugs>
Status: CONFIRMED ---    
Severity: normal CC: ago.sylvain, enthlinn, jsardid, montel, pikakolendo02, sndream
Priority: NOR    
Version: 5.2.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:

Description davidblunkett 2017-12-05 15:18:03 UTC
words less than 3 letters are ignored -err why?

I can understand that in most everyday text searching "to" or "a" is pointless but I do have unique 2 letter identifies I want to search for and this seems an arbitrary cut off.
Comment 1 Laurent Montel 2017-12-05 15:27:12 UTC
(In reply to davidblunkett from comment #0)
> words less than 3 letters are ignored -err why?

Because the number of email with 2 letters is too important.
So we need a limit for reducing number of email.

> 
> I can understand that in most everyday text searching "to" or "a" is
> pointless but I do have unique 2 letter identifies I want to search for and
> this seems an arbitrary cut off.
Comment 2 davidblunkett 2017-12-06 16:36:04 UTC
This is nonsensical -I understand that unspecific keys are not very useful but that is an issue for the user and shouldn't be enforced by the interface.

I need to do a 2 letter search that will uniquely identify 3 emails out of 1000 but this is blocked whereas there there are lots of longer strings that will be found in every single email yet these are allowed.

This is a poor policy and should be removed.
Comment 3 avlas 2017-12-23 06:50:49 UTC
(In reply to davidblunkett from comment #2)
> This is nonsensical -I understand that unspecific keys are not very useful
> but that is an issue for the user and shouldn't be enforced by the interface.
> 
> I need to do a 2 letter search that will uniquely identify 3 emails out of
> 1000 but this is blocked whereas there there are lots of longer strings that
> will be found in every single email yet these are allowed.
> 
> This is a poor policy and should be removed.

I agree with this comment. Think for instance when looking for country codes, such as UK (also being sensitive to case would help for e.g. US)

Perhaps the logi goes like this: searching 1 or 2 letters is very computationally demanding, and most of the time a user will search words of >= 3 letters anyways, so the user won't like the search process to be unresponsive after introducing the 1st or 2nd letter. 

If that would be the problem, could the search algorithm impose a delay to retrieve matches when only 1 or 2 letters are introduced? Would that be a good compromise solution?
Comment 4 avlas 2017-12-23 07:35:48 UTC
Just saw this https://bugs.kde.org/show_bug.cgi?id=387618

Are these two bugs referring to the same thing? Is this bug then fixed too by the same commit https://cgit.kde.org/messagelib.git/commit/?id=999bac0c064c600868af35852d2fe000aab09970?
Comment 5 davidblunkett 2018-01-09 12:43:42 UTC
It's not resolved!
Comment 6 davidblunkett 2018-06-28 08:21:06 UTC
This bug is so incredibly annoying please fix (also for this please add reg expressions).
Comment 7 avlas 2018-06-28 10:33:09 UTC
dolphin's filter works for any number of letters, I don't see why this has to be any different in kmail either
Comment 8 SnDream 2020-03-11 07:04:29 UTC
The three-letter limitation also appears in Chinese searches, making searching difficult.
For example, search for "通知" which is mean "announcements" in English, is impossible.
Comment 9 davidblunkett 2020-06-20 14:00:35 UTC
This is such a PITA - please fix!
Comment 10 davidblunkett 2021-08-12 11:39:24 UTC
Struck this again, the key I need to search for is "L4" - it will have one hit out of 1800 emails.  I could understand not searching live as you type until x or more characters but refusing to search at all is nuts
Comment 11 SnDream 2021-08-13 06:21:51 UTC
As an alternative, try Menu - Tool - Find mail (maybe, i'm not using english version) or type shortcut key 'S'
Comment 12 davidblunkett 2021-08-31 07:47:56 UTC
And again - today I need to find 58/1500 emails with "X7" in the subject.
Comment 13 Sylvain 2021-10-19 09:26:34 UTC
I was going to open a bug on the same issue, as it has been bugging me for several years now (should have done it earlier, sorry).

I often search for japanese names and these are often two kanjis (multibytes characters, for example 田中). I understand also the need for country code, etc.

I was looking in the source to see where this check is done and see if I could fix it (I am not a C++ programmer, but I thought it could be easy), but I couldn't find the code...

What I want to propose is that a first check is done : are the two characters multibytes (CJK) strings? are both letters capitalize? and if one is validated, the search is started. This could limit two "letters" search to CJK languages and for abbreviation. Would that be possible?

Thanks
Comment 14 SnDream 2021-10-19 12:26:22 UTC
(In reply to Sylvain from comment #13)
> I was going to open a bug on the same issue, as it has been bugging me for
> several years now (should have done it earlier, sorry).
> 
> I often search for japanese names and these are often two kanjis (multibytes
> characters, for example 田中). I understand also the need for country code,
> etc.
> 
> I was looking in the source to see where this check is done and see if I
> could fix it (I am not a C++ programmer, but I thought it could be easy),
> but I couldn't find the code...
> 
> What I want to propose is that a first check is done : are the two
> characters multibytes (CJK) strings? are both letters capitalize? and if one
> is validated, the search is started. This could limit two "letters" search
> to CJK languages and for abbreviation. Would that be possible?
> 
> Thanks

source: https://invent.kde.org/pim/messagelib/-/blob/master/messagelist/src/core/widgets/quicksearchwarning.cpp

But I have no idea what to do.
Comment 15 Shinjo Park 2022-06-03 19:02:25 UTC
*** Bug 454696 has been marked as a duplicate of this bug. ***
Comment 16 enthlinn 2023-10-12 09:55:23 UTC
It is now 2023. Obviously, this is an issue that all users will notice when they open `kmail` and want to do something serious. After many times I am pressing the `s` key to open the search dialog box, I decided to take out my reliable partner: `gdb`, download the source code and install all of symbol files, and then try to shut down this "feature" completely. 

TL;DR: if you want to disable this "feature", you need to modify at least the following places:

https://invent.kde.org/pim/messagelib/-/blob/e80b91038ba805682c129c7fa0f6e434220c83d2/messagelist/src/core/filter.cpp#L241-L249
https://invent.kde.org/pim/messagelib/-/blob/e80b91038ba805682c129c7fa0f6e434220c83d2/messagelist/src/core/widgets/quicksearchwarning.cpp#L29-L46
https://invent.kde.org/pim/messagelib/-/blob/e80b91038ba805682c129c7fa0f6e434220c83d2/messagelist/src/core/widgets/quicksearchline.cpp#L68-L81

These are hard-coded and must be recompiled and installed. And after reading the source code, I found that kmail quick search does not only limit once search to a minimum of 3 characters, but also *each word* must be greater than 3 characters. Why is it designed this way? I found the ancient commit history (that's true for 2023):

https://github.com/KDE/kdepim/commit/1e416df1618989abd4364247966e621a608893b9

Are there any performance issues? I don't know. But in my opinion, the user should at least be given a choice (to disable this).