Programmatically obtain docid for a search

8 views
Skip to first unread message

Ravi R

unread,
Aug 23, 2021, 10:55:39 PM8/23/21
to mu-di...@googlegroups.com
With the goal of writing rules for automatic refiling of some messages
(similar to sieve rules), the following mechanism would seem to work:

(defvar r/saved-docids nil)
(defun r/save-docids (msg)
(setq r/saved-docids
(cons (mu4e-message-field msg :docid)
r/saved-docids)))
(defvar r/dest-folder "/some_mailbox/some_folder"
(defun r/move-to-folder (docid)
(mu4e~proc-move docid r/dest-folder))

(defun r/docids-for-search (query)
"WON'T WORK: Obtain all docids from the mu server for QUERY"
(let ((mu4e-header-func 'r/save-docids)
(mu4e-found-func
(lambda (n)
(mapc #'r/move-to-folder
r/saved-docids))))
(setq r/saved-docids nil) ; reset the list
(setq r/dest-folder some-folder)
(mu4e~proc-find query nil 'date 'descending nil t nil)))

Of course, the preceding does not work, since we can't really store
mu4e-header-func and mu4e-found-func via let-bindings as the result is
received asynchronously. Is there another way to do it?

Background: The goal is to take messages matching a query (typically
some mailbox folder, some sender, and some date:40y..8d) and move them
into some archive folder. Ideally, the function that does this
processing can be added to mu4e-index-updated-hook making this seamless.

The alternative approach is to use GNU mailutils with sieve filters to
process these changes immediately after fetching mail (via mbsync, in my
case), but that is annoying and should be feasible via mu. It would be
fantastic if Mu::mu_msg_move_to_maildir could be exposed via a mu
subcommand (with the possibility of automatic renaming) so that this
could be done entirely from the command-line.

Dirk-Jan C. Binnema

unread,
Aug 26, 2021, 2:56:54 PM8/26/21
to mu-di...@googlegroups.com
Hi Ravi,

On Monday Aug 23 2021, Ravi R wrote:

> With the goal of writing rules for automatic refiling of some messages
> (similar to sieve rules), the following mechanism would seem to work:
>
<snip>

> Of course, the preceding does not work, since we can't really store
> mu4e-header-func and mu4e-found-func via let-bindings as the result is
> received asynchronously. Is there another way to do it?

Well... you can save when sending the command to the mu-server, and then
restore on the receiving side. But that _is_ a bit icky.

> Background: The goal is to take messages matching a query (typically
> some mailbox folder, some sender, and some date:40y..8d) and move them
> into some archive folder. Ideally, the function that does this
> processing can be added to mu4e-index-updated-hook making this
> seamless.

In general, I'm not sure if doing it semi-interactively in emacs is the
best way. Sounds like something for a procmail like tool, or...

> The alternative approach is to use GNU mailutils with sieve filters to
> process these changes immediately after fetching mail (via mbsync, in my
> case), but that is annoying and should be feasible via mu. It would be
> fantastic if Mu::mu_msg_move_to_maildir could be exposed via a mu
> subcommand (with the possibility of automatic renaming) so that this
> could be done entirely from the command-line.

...perhaps some shell scripting with the mu command line tools. Yeah,
some 'mu move' would be useful for this.

Note that you can probably do this already with a combination of `mu
find` and some shell scripting.

Kind regards,
Dirk.


--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036
Reply all
Reply to author
Forward
0 new messages