mu4e: using

182 views
Skip to first unread message

Jacek Generowicz

unread,
May 3, 2012, 9:28:19 AM5/3/12
to mu-di...@googlegroups.com
Hi,

I didn't find any built in mu4e functionality for using the mu contacts
cache. Did I miss it?

Here is a quick solution I hacked together. It uses ido to easily select
from all the contacts available in the cache. Simply inserting the
result at point offers the flexibility of using it in To: Cc: etc. or
even the message body, at will.


(defun jmg/ido-select-recipient ()
"Inserts a contact from the mu cache.
Uses ido to select the contact from all those present in the database."
(interactive)
(insert
(ido-completing-read
"Recipient: "
(mapcar (lambda (contact-string)
(let* ((data (split-string contact-string ","))
(name (when (> (length (car data)) 0)
(car data)))
(address (cadr data)))
(if name
(format "%s <%s>" name address)
address)))
(remove-if (lambda (string) (= 0 (length string)))
(split-string (shell-command-to-string "mu cfind --format=csv") "\n"))))))

(define-key message-mode-map (kbd "C-c t") 'jmg/ido-select-recipient)

Dirk-Jan C. Binnema

unread,
May 3, 2012, 2:14:20 PM5/3/12
to mu-di...@googlegroups.com
Hi Jacek,

That's really cool!

Indeed, mu4e is not using the mu cfind cache yet. My rough plan for >
0.9.8.4 would be to use guile for that, and be a bit smarter than mu
cfind.

But your solution is a good alternative -- and since probably not
everyone has guile installed, I'll integrate something like this. We'd
probably want some caching though.

Great stuff,
Dirk.
--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Jacek Generowicz

unread,
May 3, 2012, 2:43:15 PM5/3/12
to mu-di...@googlegroups.com

Dirk-Jan C. Binnema <dj...@djcbsoftware.nl>, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> writes:

[... ido-select-recipient ...]

> I'll integrate something like this. We'd probably want some caching
> though.

Agreed. I was expecting to have to add a cache, but given that the
prototype works faster (for me) than I can blink, I didn't bother. But,
yes, the real thing should probably have one.

Stephen Eglen

unread,
May 4, 2012, 4:44:02 AM5/4/12
to mu-di...@googlegroups.com
Thanks for this Jacek, that's neat!  I had been thinking about similar requirements for searching the output from 'mu cfind'.  An alternative way I had thought about it was to do something like "mu cfind > ~/.mailrc" periodically so that we could use the TAB completion facilities already present in message-mode on the mail header lines.  (That would require mu cfind outputting the aliases in a suitable format though, or a bit of sed/awk to fix it up.)

Alternatively, Message-mode does have ecomplete.el, which does 'electric completion' similar to firefox et al when typing URLs.  This would require the output from 'mu cfind' generating the ~/.ecompleterc file (e.g. via cron) and as far as I can see reading the info, there is no documentation of the format of that file.

Ideally I'd like to try both of these approaches, but time is lacking, so I thought I'd just mention them if you had not seen them.  Using the message-mode facilities for completion might be easier for those coming to mu from GNUS.  See the documentation for further info:

(info "(message)Mail aliases")

Stephen

Jacek Generowicz

unread,
May 4, 2012, 5:44:25 AM5/4/12
to mu-di...@googlegroups.com

Stephen Eglen <stephe...@gmail.com> writes:

> An alternative way I had thought about it was to do something like "mu
> cfind > ~/.mailrc" periodically so that we could use the TAB
> completion facilities already present in message-mode on the mail
> header lines. (That would require mu cfind outputting the aliases in
> a suitable format though, or a bit of sed/awk to fix it up.)

Given that mu cfind already supports a number of output formats, perhaps
it could add a maildir one?

> Alternatively, Message-mode does have ecomplete.el, which does 'electric
> completion' similar to firefox et al when typing URLs. This would require
> the output from 'mu cfind' generating the ~/.ecompleterc file (e.g. via
> cron) and as far as I can see reading the info, there is no documentation
> of the format of that file.

> Ideally I'd like to try both of these approaches, but time is lacking,

I understand. I will have approximately 0 minutes available next week to
think about mu4e, and not many more for a few weeks after that. But I
hope to do some more tinkering on this later.

> thought I'd just mention them if you had not seen them. Using the
> message-mode facilities for completion might be easier for those coming to
> mu from GNUS.

It's been about a decade since I used Gnus (or Emacs to read mail) and
have mostly forgotten what the experience was like, so I need this kind
of pointer. Thanks. Best to avoid re-inventing the wheel.

Dirk-Jan C. Binnema

unread,
May 4, 2012, 9:18:53 AM5/4/12
to mu-di...@googlegroups.com
Hi,

Jacek Generowicz <jacek.ge...@googlemail.com> writes:

> Stephen Eglen <stephe...@gmail.com> writes:
>
>> An alternative way I had thought about it was to do something like "mu
>> cfind > ~/.mailrc" periodically so that we could use the TAB
>> completion facilities already present in message-mode on the mail
>> header lines. (That would require mu cfind outputting the aliases in
>> a suitable format though, or a bit of sed/awk to fix it up.)
>
> Given that mu cfind already supports a number of output formats, perhaps
> it could add a maildir one?

Note, I think that the mutt-alias output format is the same as what
mailrc expects.

I've used mu cfind to export to org-contacts, which gives the
auto-completion etc. but it turned out that one does scale very well
(i.e.., with maybe 2000 contacts, it got really slow).

The issue is that mu cfind uses /all/ e-mail addresses, which includes
addresses seen in mailing lists etc.

So, there's also guile/examples/contacts-export which is able to sort
addresses by their 'newness' or frequency, and limit the number of
matches. I guess the 200 most frequently used addresses should be enough
for most people.

It shouldn't be hard to add some more smartness, e.g. only addresses
from messages where I am the sender + messages with my name in the
To:/Cc: field.

>> Alternatively, Message-mode does have ecomplete.el, which does 'electric
>> completion' similar to firefox et al when typing URLs. This would require
>> the output from 'mu cfind' generating the ~/.ecompleterc file (e.g. via
>> cron) and as far as I can see reading the info, there is no documentation
>> of the format of that file.
>
>> Ideally I'd like to try both of these approaches, but time is lacking,

Oh, I didn't know about ecomplete, thanks! It shouldn't be hard to hook
it up with mu4e; possibly even by filling the ecomplete database
directly from mu4e, so it will 'just work' without any user interaction,
cronscripts etc.

> I understand. I will have approximately 0 minutes available next week to
> think about mu4e, and not many more for a few weeks after that. But I
> hope to do some more tinkering on this later.

>> thought I'd just mention them if you had not seen them. Using the
>> message-mode facilities for completion might be easier for those coming to
>> mu from GNUS.
>
> It's been about a decade since I used Gnus (or Emacs to read mail) and
> have mostly forgotten what the experience was like, so I need this kind
> of pointer. Thanks. Best to avoid re-inventing the wheel.

Indeed! I already noticed a few times that I had re-implemented
message-mode functionality :/

Best wishes,
Dirk.
Reply all
Reply to author
Forward
0 new messages