| Summary: | baloosearch pattern not found when in middle of word | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | felix |
| Component: | general | Assignee: | baloo-bugs-null |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | tagwerk19 |
| Priority: | NOR | ||
| Version: | 5.93.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
felix
2022-05-02 11:04:07 UTC
(In reply to felix from comment #0) > ... is something goofy going on here? I think you'd probably say "yes" here... As you've found with your baloosearch tests, baloo does not do wildcard searches. If you search for "amp" you will get results for "ample" but not "example" (so, you can think of the search being for "amp*" but not "*amp*"). Dolphin uses the Baloo index when it thinks it can, so you'll get the same behaviour in Dolphin. If Dolphin sees that Baloo is disabled or not indexing the folder it's in, it does it's *own* search. The goofy part is that Dolphin's "own search" seems to pick up substrings; effectively an "*amp*" search. Balancing this, Baloo does recognise word boundaries so if you had done your tests with "default-testfile" files, "baloosearch test" would have found them. There's a bit of discussion in Bug 452628... I can confirm the behaviour you describe in dolphin when baloo is disabled or no index database is existing. Speed's decent, however I'd loose the ability of looking for keywords in PDF's. Also your point of word boundaries is valid. Unfortunately it does not seem appropriate to rename all files where words are made up of two words and I search for one part resulting in not finding it. The bug report you mentioned does seem equal to mine. This raises the question of closing mine since there is already one. I would like to stress, however, the suggestion to implement a *word* wildcard style for baloo as well - for filenames and keywords in text based file formats. (In reply to felix from comment #2) > ... This raises the question of closing mine since there is already one. Yes, probably makes sense to close this as a duplicate. > ... I would like to stress, > however, the suggestion to implement a *word* wildcard style for baloo as > well - for filenames and keywords in text based file formats. I agree about how useful a wildcard search would be but, with the way that Baloo is built, it could be difficult. Baloo is designed to to be *fast*, pulling results off disc as you type characters into your search - you get a steadily refined set of results as you type. It's not clear to me, with the current architecture, how you could do that with wildcards... On the other hand, maybe more powerful magic is possible, plocate is amazingly fast and provides wildcard searches, https://plocate.sesse.net/ *** This bug has been marked as a duplicate of bug 452628 *** |