GNOME Bugzilla – Bug 211640
The "Body contains" and "Body does not contain" searches are broken.
Last modified: 2013-09-10 14:02:48 UTC
I should start by commenting that Luis Villa was unable to reproduce this bug. He is accessing a IMAP server. I use POP. Not sure if that is significant or not. I am including both the "Body does not contain" and "Body contains" bugs together, because I think they are related. Anyhow, here's the report: Part1 ----- Perform a "Body does not contain" search for the string "e". Result: Instead of returning a nearly empty hit list (since basically every message has an "e" in it), I get all the messages being displayed. Furthermore, all the "e" characters in the messages are highlighted, when I open them. Part2 ----- Perform a "Body contains" search for "1". Result: At least in my case, I get an empty list. Which is ridiculous.
I think this must get fixed for 1.0. I hope someone can reproduce the failure.
Since body content is indexed for local mail, it only matches on whole words. i.e bodies that contain the whole word 'e'. This isn't changing for 1.0
Sorry, either the UI should be changed to indicate that word searching is in effect (this is not at all indicated by the UI) and there should be a help topic explaining how the indexing is done. For example, how does the indexing determine word boundaries? Is "end)" a word or is the parenthesis ignored? Otherwise, this bug should be just postponed, not marked as will not fix. This IS a bug. If you don't have time to fix it now, that's cool. But I consider this very non-optimal and confusing functionality for users. Since you don't think this can be fixed for 1.0, I will mark it as Future.
Marking as 1.0 for at least the following portion of the bug. You say that the indexer works with words. Well, I just confirmed that the "Body does not contain" search for "the" failed to exclude from the results a message containing this paragraph: ---------- > CITY OF SEATTLE MAYOR > Notes about the race for Mayor: The "Main" 3 candidates are Schell, > Nickels, and Sidran. In general, most people think there is no good choice > here. There are copies of articles supporting and opposing each candidate > at the end of this email. But in researching the candidates, I was alarmed > by the very strong and clear anti-semitism aimed at Mark Sidran. He has > certainly done things to earn people's anger. But there's no way he has > earned the degree of hatred expressed by the many anti-Sidran websites.
This still isn't being fixed for 1.0. I have no idea why it doesn't work not-matching words, maybe the index is screwed up. Turn off indexing maybe.
This is kinda bad news. What's the point of having a "Message contains" or "Body contains" query that doesn't even match full words? That's just broken. It's lame that substring queries aren't supported, but at the very least, full word queries should work. I just tried searching for "2.4.13-pre5" (which occurs in at least six messages in my Inbox). Not one hit was returned. Gah! Ettore, if you say this is acceptable, I'll drop the argument.
Does it get better if you delete the .ibex file and restart evolution? If you turn off indexing, the search is a substring search, and should work. And this is STILL not going to get fixed for 1.0. I dont intend to try and fix anything in libibex at this stage: it would be too dangerous and time consuming to try. The fix i intend for libibex is to rewrite it. Its not ettore's decision anyway.
Hi Michael, I tried exiting Evo, running killev, renaming the local/Inbox/mbox.ibex and then restarting Evo. When I searched for Message contains "2.4.13-pre5", I got one hit. That message contains the search string in the Summary value. The (at least) five messages that contain "2.4.13-pre5" in the message body were not matched. I then tried doing a Body contains search for "2.4.13-pre5". I got no hits at all. This leads me to believe that body text searching is really messed up. Also, even though I've moved my ibex file, substring matching isn't working.
This is, at the least, 1.1. Ideally 1.0 but I understand otherwise.
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
this is gonna require the ibex rewrite. btw you can't search on words with - . etc in them, they get stripped out, so it is an invalid test.
NotZed, you keep saying things like "that's an invalid test", when, in fact, the tests are perfectly valid. There is nothing in the UI that says "message contains" <text>, but you can't query for <text>-<text>. Therefore, either this is a UI bug or the functionality is busted. As far as I'm concerned, having various substrings for which matches can't found, is bogus. I ought to be able to search for any sequence of characters and find all matches. Anything less than this will confuse users, introduces friction into the user experience and makes the app less useful. I imagine you want to index the message to allow fast queries, but if you can recognize qeuries that the index based search can't handle, why not fail over to a non-index-based brute force query?
Well, I dunno, when you put in 12-4r Into google, it doesn't tell you you can't do that, yet thats not what it searches with.
Given the new indexing code this should be a little easier to 'fix', for what isn't already.
should be fixed now.