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.
(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.
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.
(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?
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?
It's not resolved!
This bug is so incredibly annoying please fix (also for this please add reg expressions).
dolphin's filter works for any number of letters, I don't see why this has to be any different in kmail either
The three-letter limitation also appears in Chinese searches, making searching difficult. For example, search for "通知" which is mean "announcements" in English, is impossible.
This is such a PITA - please fix!
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
As an alternative, try Menu - Tool - Find mail (maybe, i'm not using english version) or type shortcut key 'S'
And again - today I need to find 58/1500 emails with "X7" in the subject.
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
(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.
*** Bug 454696 has been marked as a duplicate of this bug. ***
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).