2 bugs in mew-search.el

[tdanckaert]

Hi,

I'd like to report these 2 bugs related to Hyper Estraier search.

regex in mew-search-virtual-with-est

In mew-search-virtual-with-est the list of Hyper Estraier results is not parsed correctly when mew-mail-path ends in a directory name that also appears on the IMAP host, for example when mew-mail-path is "~/Mail", and the IMAP server contains a directory "%Mail/Github".

The bug is due to the regex used:

 (format "file://.*/%s/\\(.*\\)/\\([0-9]+\\)\\(%s\\)?$"
            (file-name-nondirectory mew-mail-path))

In the case, when mew-search-est results contain messages from %Mail/Github, the regex will eat the complete path until "Github". and these results are not displayed in the Mew virtual folder.

As a workaround, I renamed my local folder to "~/Maillocal"

Replacing the .* for the first part of the path with the non-greedy .*? seems to solve the problem (I've made a pull request).

string formatting in mew-search-est

In mew-search-est, the following parameter is passed to estcmd search.

 (format "@uri STRINC %s" (mew-q-encode-string path ?%) )

If path contains _ character, these are encoded as %5F, but it looks like estcmd does not expect this encoding (using Hyper Estraier 1.4.13). For example, if mew-mail-path is "~/Mail_local", the generated Hyper Estraier command in mew-search-est is

 estcmd search -attr "@uri STRINC Mail%5Flocal/" -vu -max -1 -ord "@cdate NUMA" /home/username/Mail_local/casket/ "pattern"

which gives 0 results. Using the unencoded path instead, like

 estcmd search -attr "@uri STRINC Mail_local/" -vu -max -1 -ord "@cdate NUMA" /home/username/Mail_local/casket/ "pattern"

gives the correct results. Perhaps mew-q-encode-string is not required there?

Thank you very much,

Thomas