Menu
▾
▴
#503 search should not create folder with all-numeric name
It is possible to create a subfolder of mhe-index with an all-numeric name. For example, if using pick(1) for searches, doing a full search on "12345"[1] will create +mhe-index/12345.
This confuses nmh, which expects that if the name is all-numeric, it is a message.
In this particular case, the folder name should be something like +mhe-index/search_12345, similar to the folder name that is generated for searches on "subject" or "from". We should also make sure that the folder name is sensible for other search backends (e.g., mairix).
[1] This can be done by putting "12345" underneath the dashed line in the search form.
I wanted to understand this a little better, so I ran (mh-pick-parse-search-buffer) on a search buffer with 123 in all fields. I then put the result in the variable "foo". Here are the results of calling the various regexp-builders and mh-index-generate-pretty-name.
(setq foo '((nil . "123") (subject . "123") (date . "123") (cc . "123") (to . "123") (from . "123")))
(mh-swish++-regexp-builder foo)
-> " 123 and (subject = 123) and (date = 123) and (cc = 123) and (to = 123) and (from = 123)"
(mh-index-generate-pretty-name " 123 and (subject = 123) and (date = 123) and (cc = 123) and (to = 123) and (from = 123)")
-> "123_and__subject_=_1"
(mh-mairix-regexp-builder foo)
-> ("f:123" "t:123" "c:123" "d:123" "s:123" "123")
(mh-index-generate-pretty-name '("f:123" "t:123" "c:123" "d:123" "s:123" "123"))
-> "f:123_t:123_c:123_d:"
(mh-pick-regexp-builder foo)
-> ("-lbrace" "-search" "123" "-rbrace" "-and" "-lbrace" "-subject" "123" "-rbrace" "-and" "-lbrace" "-date" "123" "-rbrace" "-and" "-lbrace" "-cc" "123" "-rbrace" "-and" "-lbrace" "-to" "123" "-rbrace" "-and" "-lbrace" "-from" "123" "-rbrace")
(mh-index-generate-pretty-name '("-lbrace" "-search" "123" "-rbrace" "-and" "-lbrace" "-subject" "123" "-rbrace" "-and" "-lbrace" "-date" "123" "-rbrace" "-and" "-lbrace" "-cc" "123" "-rbrace" "-and" "-lbrace" "-to" "123" "-rbrace" "-and" "-lbrace" "-from" "123" "-rbrace"))
-> "123_and_subjec"
I believe the fix will be to change the let at the end of mh-index-generate-pretty-name to let* and update the out variable after truncation if it is an integer. We should ensure the result is also no longer than 20 characters to avoid violating the principle of least surprise (and the specification in the docstring).
While there is a precedent for omitting terms such as -rbrace and replacing characters with underscore, there isn't a precedent for inserting characters.
If we use "search_" for numbers, we should use it in all cases for consistency. But since mh-index-generate-pretty-name doesn't know which of the terms are "search" terms, I think we should avoid using "search".
Another idea is that if integerp returns t, then we add a "#" prefix and truncate again.
While we're in there, are there any objections to replacing more than one consecutive underscore with a single one? I think it would help the pick names a lot.
In any case, the mh-index-generate-pretty-name docstring should be amended to capture what we do.
Last edit: Bill Wohler 2023-03-13
Mike was wondering why the folder name is tied to the underlying search engine, and I would tend to agree that we should use the same folder name regardless of the search engine. Here's the search template:
I like the brevity of the mairix keywords. Thus, our folder name pattern could be:
f:<from>_t:<to>_c:<cc>_d:<date>_s:<subject>_b:<body>_a:<anywhere>.It looks like it can be easily done by updating (mh-index-do-search) to pass regexp-list instead of pattern to (mh-search). Then search-pattern in (mh-search) would be set to (funcall mh-search-regexp-builder regexp-list) as it is done now in (mh-index-do-search).
(mh-index-generate-pretty-name) would be modified as described above and operate on regexp-list instead of search-regexp.
I don't think we have any backwards compatibility issues. We don't specify the format of the folder names in +mhe-index in the documentation.
Last edit: Bill Wohler 2023-03-19