John Kitchin <jkitc...@andrew.cmu.edu> writes: > Eric Abrahamsen writes: > >> The following message is a courtesy copy of an article >> that has been posted to gmane.emacs.orgmode as well. >> >> John Kitchin <jkitc...@andrew.cmu.edu> writes: >> >>>> >>>> Let's see... the org-contacts vs BBDB issue isn't a big deal, since >>>> Gnorb doesn't actually do all that much with contacts right now. I'd be >>>> happy to add tweaks to it to make it more org-contacts friendly. >>>> >>>> Email tracking is a bigger issue. Gnorb uses the Gnus registry to track >>>> correspondences between messages and headlines, and obviously none of >>>> that would work with mu4e. >>>> >>>> Earlier versions did tracking by storing message ids as a property on a >>>> headline. I suppose I could go back to doing that in a mu4e-specific >>>> library. >>> >>> Message id tracking is likely the way to do it in mu4e. mu4e links seem >>> to store this for links. >>> >>> [[mu4e:msgid:bn3pr0301mb0851db3e4c53993daa1e8a98b2...@bn3pr0301mb0851.namprd03.prod.outlook.com]] >> >> Yup, I think most of the MUA links end up looking something like that. >> Message IDs are the one constant across MUAs and (most) mail sources, so >> everything in Gnorb is keyed to that. > > It is pretty easy to get these from a message. I use this variable in a > send callback function: > > (setq *email-message-id* > (concat > "mu4e:msgid:" > ;; borrowed from > https://github.com/girzel/gnorb/blob/master/gnorb-utils.el#L137 > (replace-regexp-in-string > "\\(\\`<\\|>\\'\\)" "" (mail-fetch-field "Message-ID")))) > > and then later use > (org-set-property "Message-ID" *email-message-id*) > > and I get a clickable link in the property that will go back to the > message (after mu indexes again for freshly sent emails).
[...] > This seems to do what you describe. When I run it, I get an mu4e buffer > with those two messages in it. Basically you just create a mu query. > > #+BEGIN_SRC emacs-lisp > (let ((ids '("871teq3c9p....@ericabrahamsen.net" > "201508260407.t7q479ls026...@relay.andrew.cmu.edu") )) > (mu4e-headers-search > (mapconcat > (lambda (id) > (concat "msgid:" id)) > ids > " or "))) > #+END_SRC All this looks very encouraging! >>>> Another thing I find hugely useful is automatically transferring files >>>> attached to incoming messages to Org headings (via org-attach). >>>> Presumably mu4e has a way of getting at the attachments on a message, so >>>> in theory this wouldn't be that hard, either. >>> >>> This sounds pretty interesting. I have never gotten that into >>> attachments, but this might change my mind. There are functions in mu4e >>> to view and save attachments, so this might not be hard. >> >> Much of my work involves throwing attachments around (or rather, >> receiving attachments and sending back plain text whenever possible), >> so this is pretty crucial for me. While org-attach is very sound, I >> found its surface-layer interface a bit cumbersome, and this makes it a >> lot easier to use. > > Me too ;) I just have not progressed to org-attach yet. I usually have > to edit the attachments. How easy is it to reattach them to send back? When you use `gnorb-org-handle-mail' on a heading, that composes a new reply to most recently-associated message (or does something else, depending), and runs `map-y-or-n-p' over the org-attach files, offering to attach them to the outgoing message. This works pretty well for me. The only org-attach commands I'm really missing now would be `org-attach-copy-attachment' (to somewhere else on my filesystem), and `org-attach-refile-attachment' (to move an attachment to a different heading). Anyway, all looks promising! Now to find the time... Eric