I’ve been a happy user for ~5 years. In the last 20 years of heavily using email, it’s been overall the best mail user agent I’ve seen. Strongly recommended.
Some things that set mu4e apart for me: Super fast search and UX, ability to handle multiple email addresses transparently, ability to use Org mode capture templates and good support for viewing HTML emails. There’s many more good reasons, if we want to get geekier, for example the ability to use procmail (spam, auto sorting, etc), the ability for offline mails, very good GPG support, and much more^^
This is one of the major wins. Mu’s Xapian backend chews through heaps of email and gives incredible search results. I’d completely skipped any type of filing to folders; it just works.
The only reason I’m not using it right now is that we lost the war on HTML email and bottom posting, so I’ve surrendered and gone to Outlook so my coworkers stop asking me why my email comes out funny on their phones.
If anyone knows a good set of hooks to make mail-mode transform to “quasi-nice HTML” – turn > into a blockquote, maybe * and _ to <b> and <u>, etc., I’d love to see it.
Update 2: If I understand you correctly, your issue was that people read mails on their phone and that you used fixed with mails (maybe 74 chars). That’s easily fixed by using format flowed. The config for that is a one liner in mu4e.
Thanks for the screencast and blog post: they look like they will still be worth a peek to try to improve my environment! I’ll also have to take a look at org-mu4e as well – funny enough, I used mu4e-org a ton to get emails in my agenda… wish I’d have thought about going the other direction ;-)
That’s easily fixed by using format flowed. The config for that is a one liner in mu4e.
Two problems:
f=f just doesn’t work with the MUAs I’m emailing to (Outlook, some Android mail users). 998-wide lines, as in the proposal there, were OK, but:
Beyond the “funny phone” problem the real problem is that the users I communicate with almost always expect a very specific thing: HTML emails generated by Outlook, period. Plain text emails were never workable because the use of highlights/tables/etc. was essentially stripped out.
But I’m definitely going to check out org-mu4e though to see if it fits. It probably won’t take a ton to line it up to look like Outlook…and if I can get close enough it might be worth it.
Thank you for the information that format=flowed by default doesn’t work well with some clients like Outlook. The additional configuration of setting the maximum allowed width seems like a good workaround. I just confirmed that it works with Outlook 365 (in my tests).
FWIW, based on my experience, f=f works well at least with Apple Mail and iOS.
As for mail threads that let HTML prevail on responding whilst sending plain text, that’s probably going to be a hard problem, indeed. I might be lucky, because in my experience people with HTML mailers don’t start threads. Especially not with Outlook (365) which doesn’t seem to have the capability to quote from the previous mail. And without quoting, longer mail threads become completely unintelligible quite fast. Having said that, I do understand that some people prefer to communicate in this manner all the time anyway^^
In any case, all the best, and thank you, again for the additional information on f=f!🙏
That is not my experience. Even things like bu (Unread messages) take ~5 seconds. notmuch on the other hand has always been super fast. Maybe I’m doing something wrong?
I’ve got a mail archive of just short of 40k messages
I’ve got around 165K, not significantly more. Calling mu from the CLI is instantaneous. It is when I call it from Emacs that it takes ~5 seconds. The issue is likely on the Emacs. I have a similar experience in the three machines I’ve setup mu4e in.
$ time mu find flag:unread >& /dev/null
real 0m0.016s
user 0m0.006s
sys 0m0.010s
puercopop@PuercoDesktop:~
$ find Maildir -type f | wc -l
165508
Thanks, that did it. The gc-cons-threshold took it down to 2 seconds and the read-process-output-max to instant. Looks like I only need to update the read-process-output-max
I managed to get this up just yesterday for my work gmail account. I haven’t managed to figure out how to setup multiple gmail accounts by using the recommended contexts just yet. The contexts example is a bit naive and doesn’t talk about separating Maildirs for each account refresh rates etc.
So far the look and feel of mu4e is very good I must say.
What a coincidence; I just set this up yesterday, and it works pretty well. I wanted automatic signing of all messages I sent, as well as automatic encryption when I reply to an encrypted message. That’s easy to set up with mu4e, which is great. The only thing I don’t understand is the seen/new vs. read/unread flags. Seems to me that seen/new is automatic, where as read/unread is manual. In my mind they mean the same thing. Why have both?
Last I checked all the built-in MUAs in Emacs are written synchronously; any operation which takes a nontrivial amount of time blocks the entire UI. They’re also not built with the assumption of search in mind; at beast search is tacked on afterwards as an advanced optional feature rather than being used as the heart of the entire interface.
I haven’t looked into the workings of any of the three (MH, Rmail, and Gnus, I’m assuming) in particular detail, but I think this really depends on how you use them. MU shells out to an external process for most of its features; so does MH, and when I used it I never experienced any slowdown in usage. The same with both Rmail and Gnus, working on a local spool, and I’ve heard that connecting to a local mail server in Gnus also has fine speed.
Search is the big one. I never found advanced search particularly advantageous, but by default all three are pretty bad. All of them can have something like Mairix or Notmuch tacked on, but that’s it - it feels tacked on, and is less cohesive than something designed around search.
As a long time notmuch user: How do they differ? From when I quickly tried mu4e a while back it mainly seemed to offer a slightly different UI. The workflows mostly seemed to be the same.
I haven’t really used notmuch, so I cannot really speak to that. I mentioned it, because with regards to ‘search based’ mail workflows (that are not Gmail or similar) notmuch seems to be more well known.
Having said that, the search interfaces are similar to what I know of it.
I submitted a few patches to mu4e a few months back for a university project (it still hasn’t been merged because the maintainer doesn’t use branches for some reason just got merged), and while I didn’t quite like it before (too fidgety, spams the echo area, has a wasteful spash screen, etc – things I consider bad style), and feel even more uninterested in it now, having have seen it’s internals. The entire mode of communicating with the mu server seems very ad hoc. The style is often inconsistent and looking into mu – which is currently a mix of C and C++ didn’t make the impression any better. Search seems to be the only thing that works well, though for my purposes mairix has always been enough.
But then again, who am I to speak, since I use Rmail.
I assume your closing line is ironic, but for anyone else reading I want to encourage at least a look at Rmail if you have simple email needs. It’s not hard to set up, has a surprisingly extensive feature set, and doesn’t require any external programs. Of all the Emacs mail programs, it was the one I was most happy with using.
The “joke” was that rmail’s implementation is also quite messy, which can be seen in the way it manages windows. I was planning to submit a few patches to fix it, but something like that would nearly require a full rewrite.
It’s mentioned very briefly on https://distinctly.pink/me/colophon.html, under the communications header. My current workflow is partially using it and partially using mutt because there are quite a few features I haven’t got figured out yet (html mail, replying). The main thing I wanted from it was to be able to use it within Acme.
I keep changing bits semi-regularly, but I’ve been working on an extensive writeup as I use it; once I feel fairly comfortable in its ability for day-to-day tasks I intend to finish that up and share it.
I’ve been a happy user for ~5 years. In the last 20 years of heavily using email, it’s been overall the best mail user agent I’ve seen. Strongly recommended.
Some things that set mu4e apart for me: Super fast search and UX, ability to handle multiple email addresses transparently, ability to use Org mode capture templates and good support for viewing HTML emails. There’s many more good reasons, if we want to get geekier, for example the ability to use procmail (spam, auto sorting, etc), the ability for offline mails, very good GPG support, and much more^^
The initial configuration is a little bit of work, but it’s paying off for years to come. If you’re looking for a setup apart from the docs, here’s my config: https://github.com/munen/emacs.d/blob/master/configuration.org#mu4e
I’d second this.
This is one of the major wins. Mu’s Xapian backend chews through heaps of email and gives incredible search results. I’d completely skipped any type of filing to folders; it just works.
The only reason I’m not using it right now is that we lost the war on HTML email and bottom posting, so I’ve surrendered and gone to Outlook so my coworkers stop asking me why my email comes out funny on their phones.
If anyone knows a good set of hooks to make mail-mode transform to “quasi-nice HTML” – turn > into a blockquote, maybe * and _ to <b> and <u>, etc., I’d love to see it.
Hi owen
Thanks for bringing up this valid concern. I’ve heard it often before, but personally have not encountered an issue. To share my experience and setup, I quickly created a screencast and a blog post that shows how I work with HTML emails: https://200ok.ch/posts/2020-05-27_using_emacs_and_mu4e_for_emails_even_with_html.html
All the best and good email consumption/writing(;
Update: And now I’ve just read that you’re talking about the opposite waylol
Well, there’s a built-in way to transform Org to HTML, but I haven’t used it: https://github.com/djcb/mu/blob/master/mu4e/org-mu4e.el
Update 2: If I understand you correctly, your issue was that people read mails on their phone and that you used fixed with mails (maybe 74 chars). That’s easily fixed by using format flowed. The config for that is a one liner in mu4e.
Thanks for the screencast and blog post: they look like they will still be worth a peek to try to improve my environment! I’ll also have to take a look at
org-mu4eas well – funny enough, I usedmu4e-orga ton to get emails in my agenda… wish I’d have thought about going the other direction ;-)Two problems:
But I’m definitely going to check out org-mu4e though to see if it fits. It probably won’t take a ton to line it up to look like Outlook…and if I can get close enough it might be worth it.
Thank you for the information that
format=flowedby default doesn’t work well with some clients like Outlook. The additional configuration of setting the maximum allowed width seems like a good workaround. I just confirmed that it works with Outlook 365 (in my tests).FWIW, based on my experience,
f=fworks well at least with Apple Mail and iOS.As for mail threads that let HTML prevail on responding whilst sending plain text, that’s probably going to be a hard problem, indeed. I might be lucky, because in my experience people with HTML mailers don’t start threads. Especially not with Outlook (365) which doesn’t seem to have the capability to quote from the previous mail. And without quoting, longer mail threads become completely unintelligible quite fast. Having said that, I do understand that some people prefer to communicate in this manner all the time anyway^^
In any case, all the best, and thank you, again for the additional information on
f=f!🙏That is not my experience. Even things like bu (Unread messages) take ~5 seconds. notmuch on the other hand has always been super fast. Maybe I’m doing something wrong?
I like the UI of mu4e more fwiw.
buis near instant for me, as are other queries. I’ve got a mail archive of just short of 40k messages. Maybe you’ve got significantly more?I’ve got around 165K, not significantly more. Calling mu from the CLI is instantaneous. It is when I call it from Emacs that it takes ~5 seconds. The issue is likely on the Emacs. I have a similar experience in the three machines I’ve setup mu4e in.
I don’t have nearly as many mails as you so I’m not certain, but you can try bumping up
gc-cons-thresholdandread-process-output-max:Thanks, that did it. The
gc-cons-thresholdtook it down to 2 seconds and theread-process-output-maxto instant. Looks like I only need to update the read-process-output-maxI managed to get this up just yesterday for my work gmail account. I haven’t managed to figure out how to setup multiple gmail accounts by using the recommended contexts just yet. The contexts example is a bit naive and doesn’t talk about separating Maildirs for each account refresh rates etc.
So far the look and feel of mu4e is very good I must say.
What a coincidence; I just set this up yesterday, and it works pretty well. I wanted automatic signing of all messages I sent, as well as automatic encryption when I reply to an encrypted message. That’s easy to set up with mu4e, which is great. The only thing I don’t understand is the seen/new vs. read/unread flags. Seems to me that seen/new is automatic, where as read/unread is manual. In my mind they mean the same thing. Why have both?
What advantage does this have to Emacs’ built in client?
Which emacs built-in client? :D There are three different ones that come bundled with emacs by default.
Last I checked all the built-in MUAs in Emacs are written synchronously; any operation which takes a nontrivial amount of time blocks the entire UI. They’re also not built with the assumption of search in mind; at beast search is tacked on afterwards as an advanced optional feature rather than being used as the heart of the entire interface.
I haven’t looked into the workings of any of the three (MH, Rmail, and Gnus, I’m assuming) in particular detail, but I think this really depends on how you use them. MU shells out to an external process for most of its features; so does MH, and when I used it I never experienced any slowdown in usage. The same with both Rmail and Gnus, working on a local spool, and I’ve heard that connecting to a local mail server in Gnus also has fine speed.
Search is the big one. I never found advanced search particularly advantageous, but by default all three are pretty bad. All of them can have something like Mairix or Notmuch tacked on, but that’s it - it feels tacked on, and is less cohesive than something designed around search.
mu is search based. Maybe you’ve heard of notmuch - it’s a similar approach, but different^^
As a long time notmuch user: How do they differ? From when I quickly tried mu4e a while back it mainly seemed to offer a slightly different UI. The workflows mostly seemed to be the same.
I haven’t really used notmuch, so I cannot really speak to that. I mentioned it, because with regards to ‘search based’ mail workflows (that are not Gmail or similar) notmuch seems to be more well known.
Having said that, the search interfaces are similar to what I know of it.
I submitted a few patches to mu4e a few months back for a university project (
it still hasn’t been merged because the maintainer doesn’t use branches for some reasonjust got merged), and while I didn’t quite like it before (too fidgety, spams the echo area, has a wasteful spash screen, etc – things I consider bad style), and feel even more uninterested in it now, having have seen it’s internals. The entire mode of communicating with the mu server seems very ad hoc. The style is often inconsistent and looking into mu – which is currently a mix of C and C++ didn’t make the impression any better. Search seems to be the only thing that works well, though for my purposes mairix has always been enough.But then again, who am I to speak, since I use Rmail.
I assume your closing line is ironic, but for anyone else reading I want to encourage at least a look at Rmail if you have simple email needs. It’s not hard to set up, has a surprisingly extensive feature set, and doesn’t require any external programs. Of all the Emacs mail programs, it was the one I was most happy with using.
The “joke” was that rmail’s implementation is also quite messy, which can be seen in the way it manages windows. I was planning to submit a few patches to fix it, but something like that would nearly require a full rewrite.
Oh that makes sense. I did occasionally have some issues and the source also put me off, but I solved that by switching mua to one of my own devising.
Oh, cool. Is it public or have you written about it? I would be very interested to see what you came up with.
It’s mentioned very briefly on https://distinctly.pink/me/colophon.html, under the communications header. My current workflow is partially using it and partially using mutt because there are quite a few features I haven’t got figured out yet (html mail, replying). The main thing I wanted from it was to be able to use it within Acme.
I keep changing bits semi-regularly, but I’ve been working on an extensive writeup as I use it; once I feel fairly comfortable in its ability for day-to-day tasks I intend to finish that up and share it.