qlog: Search in should not need exact matches

[Nicholas Allen]

When I type a search term into the qlog search text field it would be nice if the string entered did not have to match exactly.

So "bug fix button" would match "fixed a bug in button where.."

essentially qlog would break the search term down into words (white space would be irrelevant except to define the words) and then check if the message contained any of the words. It would work a bit more like google and spotlight search. The user could always surround the search term in quotes if they want words to appear together in a certain order.

[Nicholas Allen (nick-allen)]

Sorry that should be "...then check if the message contained *all* of the words"

[Lukáš Lalinský (luks)]

This is too much to do at real-time on any bigger project, it would probably need a precalculated index.

[Gary van der Merwe (garyvdm)]

You can currently search with regular expressions. "bug.*fix.*button" would match "fixed a bug in button where.."

[Nicholas Allen (nick-allen)]

But it wouldn't match that. In your expression "bug" would have to occur before "fix". As long as the search happens in a background thread and can incrementally update the results on the view thread there would be no performance problems and it would not lock up the GUI so would be fine even without an index.

[Alexander Belchenko (bialix)]

Lukáš Lalinský пишет:
> This is too much to do at real-time on any bigger project, it would
> probably need a precalculated index.
>
May be one day QBzr will use bzr-search plugin under the hood...

[Nicholas Allen (nick-allen)]

Until then it should still filter and do it in the background with some visual indication that it is still processing and without locking up the event thread. Please don't make it select the first entry.

[Gary van der Merwe (garyvdm)]

I've merged some code to trunk that integrates qlog with bzr-search.

There is still an issue with the suggestions completer. It only makes suggestion on the first word. This is the behavior of QLineEdit and I don't know how to change it.

[Gary van der Merwe (garyvdm)]

Has anybody been using this? Any feedback?

[Nicholas Allen (nick-allen)]

I just installed the latest trunk but it does not seem to work for me. For example, I have indexed my qbzr trunk branch and then run bzr qlog command. When I search for "option hid" I would expect revision 429 to be matched ("qinit: Hide hidden options from the 'formats' combo and add a link to 'help formats'") but nothing is shown in the list. Not sure what I could be doing wrong...

[Gary van der Merwe (garyvdm)]

Hi Nicholas

Thanks for checking it out.

2 Questions:
* In the search type combo box, do you see "Messages and File text (indexed)"?
* If you search for "options hidden" does it work?

Searching for "option hid" does not work for me. I guess I could get bzr-search to do this though.

[Nicholas Allen (nick-allen)]

I see the "Messages and File text (indexed)" in the combo box and "options hidden" works for me. I guess it needs complete word matches. Personnaly, I think it would be better if the exact words did not have to be typed (this is more how google, spotlight and other search engines work). But great work so far and thanks for implementing this so quickly ;-)

[Gary van der Merwe (garyvdm)]

I thought of an easy way to not require exact words. I'll code it up soon.

[Nicholas Allen (nick-allen)]

Thanks again!

[Alexander Belchenko (bialix)]

I have hit with this bug recently.

search (without bzr-search plugin) can't be used if I want to find version number.

Say I have in commit messages both mentioned "version 7.3" and "v.7.3". But the search for 7.3 does not find the commit message where "v.7.3" is used. I found this very strange. I understand that 17.3 should not match, but maybe expect to find only from the beginning of the world and think that dot is the part of the word is not very good idea.