search results different to buku
Hi. I love this package. However, I have noticed that the search returns are often not the same as those of buku (run externally on command line). In particular, unlike buku, ebuku seems to be treating multiple words as a single search string. For example when running ebuku-search-on-all and providing the keyword? foo bar, only entries in which foo and bar occur as foo bar will be matched. Entries such as foo a bar or bar foo will not be matched, whereas both of these will be matched with buku. Or am I missing something?
Also, is there any scope for adding --deep?
Regards Murray
Emacs 27.2 Arch linux ebuku (20220106.902) via melpa
No, you're not missing something - i've rarely used, or use, Buku outside of Ebuku, and so didn't realise that Buku interpreted a space-separated list as OR'd, rather than as a phrase (which is what i usually need), and that's reflected in the prompt saying "Keyword?" rather than "Keyword(s)?" However, Ebuku should certainly follow Buku's behaviour by default, whilst at the same time ensuring it's still possible to search for a space-separated phrase.
i also wasn't aware of --deep, but yes, that should be supported as well.
Unfortunately, for a variety of reasons, i'm struggling to find the resources to work through my backlog of ICT stuff, so i'm not likely to get to either of the issues you raise soon - sorry. So what i'll do is open a separate issue for --deep and add "help wanted" tags to both issues.
would you consider replacing lines 322 - 326, with something like:
(call-process-shell-command ebuku-buku-path nil t nil
(mapconcat 'identity
(list "--np" "--nc"
"--db" ebuku-database-path
"--sall"
(mapconcat 'identity args " ")
) " ")
)
This might prevent the call-process from being sent a collection of strings. Basically, it seems like the search terms (both search and exclude) are being sent as strings.
With the above, if the keyword? is given in quotations, then the phrase will be maintained
Please bare in mind, I am not very proficient in elisp and therefore, the above suggestion might not be appropriate for some reason - although it seemed to work in the circumstances that I tested.
At this particular moment i don't remember if there was a specific reason i chose to use call-process rather than call-process-shell-command, but there might well have been .... Certainly someone submitting a PR to address this issue would need to make sure that such a change doesn't create problems elsewhere.