552576 - quicksearch needs better/smarter handling of multi-word search

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Right now, if you do a quicksearch on "foo bar", with, say, the "Subject or From filter" selected, it will find messages that have "this is a foo bar message" as the subject, but not "let's have a foo and bar message".  It should really search for messages that contain all of the space-separated words, and not that contain the explicit string that's specified.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

After talking to asuth, this sounds like an easy win, both in terms of code and UX.  Bryan, whaddya think?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

This is almost certainly a dupe, but, this bug is the winner.

I'll take care of this as part of bug 545955.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to comment #2)
> This is almost certainly a dupe, but, this bug is the winner.

most probably  Bug 240454 -  Add AND / OR searching to quick search


bear in mind, that quick search results displays "Save results as saved search" to the user.  Is it possible to make a saved search with the solution you have in mind?

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #3)
> bear in mind, that quick search results displays "Save results as saved search"
> to the user.  Is it possible to make a saved search with the solution you have
> in mind?

Yes and no.  Yes, it would be very easy to save it as a saved search.  No, we can't do it because the dialog that allows you to edit saved searches cannot express the grouping constructs used by the message filter bar.

Comment 5

[Thomas D. (:thomas8)]

Hey everyone, it's great news you're starting to care for a better filter experience. However, this bug is really a dupe, and guess what, it was me who posted the full-fledged equivalent bug 522985 of age-old Seamonkey bug 123788 who has just had his 8th birthday. I really wonder why I never received any response for bug 522985...

Actually, I propose duping this bug against existing bug 522985, as bug 522985 is in a much more advanced state,
covering the details of everything needed: concept/benefits, use cases,
screenshots, implementation details, even draft documentation (in the screenshot
attachment 406950 [details]).

-> This bug should be duped against existing and more advanced bug 522985.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Thomas, you are to be commended for providing a screenshot and a detailed explanation of how the functionality should work.  Unfortunately, we don't really go through bugzilla looking for enhancement requests; a better venue would be the Thunderbird getsatisfaction instance.  It is our hope that in that location enhancement requests can find like-minded users and hopefully interested add-on developers will work to bring the ideas to fruition through an add-on.  The add-on can then potentially migrate into the core.

The general request of phrase splitting is something that I'm subsuming into my work on the message filter bar (which is currently an add-on); attaching a bug to it is merely a formality for tracking purposes.  The feature is low-hanging fruit because of the existing gloda implementation of phrase splitting, which is the implementation I'm using, so there doesn't need to be much/any discussion.

Comment 8

[Thomas D. (:thomas8)]

> The feature is low-hanging fruit because of the existing gloda implementation
> of phrase splitting, which is the implementation I'm using, so there doesn't
> need to be much/any discussion.

Andrew, will gloda's implementation of phrase splitting have the same implied pattern matching as current quick search, so that we can still enter partial strings from the middle of a word?

Desired Pattern Matching for this bug (as in current quick filters)
(It's probably the wrong syntax, but you get the idea)

Find messages WHERE (
  ((Subject = *foo*) Or (Sender = *foo*) Or (Recipient = *foo*))
  AND
  ((Subject = *bar*) Or (Sender = *bar*) Or (Recipient = *bar*))
)

Comment 9

[Frédéric Buclin]

(In reply to comment #6)
> Unfortunately, we don't
> really go through bugzilla looking for enhancement requests

And why don't you look for existing RFEs in bmo? What's the point of doing that? That's no-sense. Just prevent everybody except the Tb team from filing bugs in the Thunderbird product rather than letting people with unmanaged requests for years.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #8)
> Andrew, will gloda's implementation of phrase splitting have the same implied
> pattern matching as current quick search, so that we can still enter partial
> strings from the middle of a word?

Yes; we're still using the quick-search innards, we're just using gloda's parsing code to break up the user's query.

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #9)
> And why don't you look for existing RFEs in bmo? What's the point of doing
> that? That's no-sense. Just prevent everybody except the Tb team from filing
> bugs in the Thunderbird product rather than letting people with unmanaged
> requests for years.

We don't have a time machine to go back and change how things were done and expectations were set years ago.  We are planning to do a big thing where we explicitly say enhancement requests should move to getsatisfaction, but we expect a lot of people to (quite reasonably) be upset when we do this.  In order to help some good come from this rather than just making everyone unhappy, we want to wait to do this until the extension development story is improved.  We are almost there thanks to the Jetpack SDK and various efforts in Thunderbird, but we are not there yet.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

This is implemented by bug 545955 and will be available in Thunderbird 3.1 beta 2.