* A daemon that pulls new mail from my IMAP servers to my local maildir as soon as it arrives. (I know mutt has an IMAP mode, and it looks like that's aerc's primary mode of operation, too, but I like to have a local copy of my entire mail archive.)
* Rendering plain text markdown into multipart/html emails. I love me some plaintext, but no one else in my life even knows what a terminal is. 80-char lines are too short for desktop displays and too long for small phones (leading to awful linebreaks), which makes me the guy whose emails never look right.
What you want is format=flowed emails.
Check the mutt manual (http://www.mutt.org/doc/manual.txt for format=flowed and this blog post (https://brianbuccola.com/line-breaks-in-mutt-and-vim/).
And for details on format=flowed, read here: https://joeclark.org/ffaq.html
That said, it's nice to see a new text-oriented mail client. I remain skeptical about Unix interactive text-mode applications, though. Unlike classical Unix tools, more complex interactive applications do not compose well. They are little silos.
I was a long term Mutt user, but I eventually moved my email into Emacs. That was because Emacs applications feel part of a consistent environment, a text-mode Lisp VM. They can easily talk to each other, and you can extend them beyond their designers ideas.
On Mutt on the other hand, any non-trivial extension was just a pile of hacks. For example, multiple accounts.
I encourage HN users to take a look at Notmuch, both as a MUA inside Emacs or elsewhere, it has a really nice architecture. It's kind of a side-effect free mail user agent.
See also: https://github.com/neomutt/neomutt/issues/587
Also this article: https://fastmail.blog/2016/12/17/format-flowed/
The only solution is HTML and multipart emails.
Edit: added link to article
Nothing makes them "too short for desktop displays". Text is not supposed to fill all/most of the available display width:
“Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line(counting both letters and spaces) is widely regarded as ideal.”
-- The Elements of Typographic Style Applied to the Web
That is pretty obvious, but every modern email client is able to deal with text wrapping itself. The only effect of the 80-char limit today is that of butchering your emails, especially on mobile. Since format=flowed is not supported enough, the only solution here is HTML.
Shorter lines are easier and faster to read and you don’t have to turn your head back and forth every line. This is what German Typographers would call a Bleiwüste, which means “lead desert” and translates to wall of text. And they call it that for a reason. Typographers use a wall of text when they want to disencourage users from reading it (legal text etc).
Column based layouts (like in newspapers) don’t work well with scolling pages, but limited line width certainly does. Scrolling doesn’t really cost the user much and on top of that smartphones limit the line width anyway, so users get a more consistent design.
On my computer I can resize windows and within some apps such as my email app the display view so that it meets what is optimal for me and not some generalized value. It is not unreasonable to expect the text presented to me to reflow to meet my preference.
The advice given wasn't based on the technology of the era, but on the optimal line length for reading in general.
That's invariant to how more wide a screen one has (or to whether the "text" looks not wide enough compared to the screen), and based on how far the eyes should go to read something, and whether the reader loses their place (line they are in etc) by the time the roll back and forth at the end of a line to start the new one.
>Instead of being fixed width the text should be reflowed to properly fill the viewing window.
That's the worst possible situation, and not found to be good by any reading research (on paper or screen).
Both the expectation that text will reflow and that 66 character line lengths are too short is not unique to me. A quick Google search returns a large number of hits regarding people looking for ways to have either the emails they send or receive be reflowed in their email app.
Eh... What else is it supposed to do in a terminal? Of course I want text to fill as much space as possible.
The ideal to me would be optional, backwards compatible re-flow like RFC 3676, but that doesn't seem to have caught on.
I spent a lot of time fighting with malformed MIME messages, etc. Then adding on GPG-support, and handling the UI, all becomes a huge time-sync.
Still I now have a client that I love, even if nobody else does!
My god. I tried parsing my gmail “All Messages” once as part of a project. It ended up being an amazing corpus of a zillion ways to do MIME wrong. Project didn’t get off the ground because even after handling all of my weird cases, every new user ended up blowing up the parser again. Yeesh.
fetchmail + procmail do just that. Use the Unix way :)
What's wrong with fetchmail? Granted, it's not "as soon as it arrives", but you can run it every minute if you want.
(I also use unison to keep the mail directory synchronized between all my machines.)
Also, how many times have you spoken to someone on the phone for them to say "I've just sent you the details.... can you see it yet?"
Within seconds, really? I haven't encountered a single service like that.
> Also, how many times have you spoken to someone on the phone for them to say "I've just sent you the details.... can you see it yet?"
True but there's an easy solution: Fire up a terminal or even use a keyboard shortcut to run offlineimap manually within a split second.
I've had a variant of this due to using a custom domain with a small email provider that was either slow or greylisting; the second-factor login email for GOG took longer than 15 minutes to arrive, by which time it had expired. I had to keep trying until it came through quickly enough.
RFC 3676  describes the format MIME parameter for text/plain content type documents which solves this issue. Unfortunately, it does not work well when sending inline patches via email since it introduces trailing whitespace.
How, unless the MUA is modifying quoted text beyond prefixing each line with >.
> intermixing mail clients that handle it with those that don't (or have been intentionally configured to ignore it because it mangles mails) produces poor results
I participated in many lengthy discussions in deeply nested threads on usenet with an email client (Thunderbird) that had format=flowed enabled for the text/plain posts that I was sending. I never noticed any issues when viewing posts I made or other posts that were descendants of my posts. That is, no problems with line wrap or other rendering issues (either when looking at it in Thunderbird's view pane or looking at the raw message text).
> it often breaks signatures;
It shouldn't break them if the client applies the signature itself.
> it makes it harder to quote and reply to emails
I don't see how this would be the case. When you reply to an email, the MUA should prefix each line in the body of the original message with a > character. Whether those lines have a single trailing whitespace character or not shouldn't make a difference in terms of quoting the original text.
> it means the person on the other end will not see exactly what you sent.
Unless you have text that requires wrapping at specific line lengths, they will see what you sent. If their client supports the flowed format, the lines will be rewrapped to your screen width. If their client does not, then they see the original raw text with trailing whitespace at the end of each line (other than the last line of each paragraph) which essentially is not visible to the reader unless they've configured their client to display a marker for trailing whitespace.
As far as I'm aware, mail clients typically don't modify quoted text beyond prepending each line with a > character. Even if the trailing whitespace is lost, then you'll just have a conventional hard wrapped message (which is no different than just using a mail client that doesn't support format=flowed).
> The concept of "format=flowed" itself can get mangled if someone with a mail client that doesn't support it replies.
Not in my experience. If they remove the trailing whitespace, then it's essentially hard-wrapped again. If they don't, then it's still flowed.
> And yes, people do send things like ASCII art or underlined text or code or other things where whitespace and wrapping matters.
In that case, the flowed option isn't suitable. The RFC I referenced does support a fixed option for the format parameter which would address that issue. Also, Thunderbird did not attempt to append whitespace to previously quoted material if it didn't have it already.
In any case, the flowed format would work perfectly for this particular thread since no one is hard wrapping anything.
You can do this with fetchmail and procmail.
I completely agree! That's exactly the feature I requested, for exactly the same reasons, to the developers of Neomutt. I was pleasantly surprised when it turned out they were open to the idea. They got it implemented eventually. The discussion is here:
I've used both OfflineIMAP & mbsync for this; I'd recommend the latter these days. Works great.
> Rendering plain text markdown into multipart/html emails.
I have a feeling you could do something with emacs & one of its mail modes to do this, by slapping something into a hook … Ah, this guys looks to have come up with a way: https://ioctl.it/posts/2015-03-18-emacs-html-mail.html/
text/plain (markdown) -> multipart/alternative with neomutt
macro compose K "| pandoc -f markdown -o /tmp/neomutt-alternative.html<enter><attach-file>/tmp/neomutt-alternative.html<enter><tag-entry><previous-entry><tag-entry><group-alternatives>"
Mutt can then use the synched directory from offlineimap.
I don't know that any offline-sync daemons uses IDLE though. isync / mbsync doesn't seem to either.
That's not "have IDLE support".
A cron-based workflow is when you periodically check for work to do rather than get notified that there's work to do.
What I would wish for is some way to render the html link text as well as the address in the terminal, so that I can easily open those in a browser.
I have looked into a way to convince w3m to do that, but haven't found one yet.
But WOW. It's the e-mail of my dreams.
Take my money, damn you!
EDIT: I may have been seduced by the clicky
keyboard noises in the video. But no! Is good!
EDIT2: I forgive you for Wayland.
I work on free software full-time now thanks to the support of the many people who donate to my work :)
Lots of people help with these projects, too. aerc 0.1.0 includes contributions from a total of 16 authors.
EDIT: I'm getting about 20kb/s download from sr.ht where the video is hosted. Definitely not an issue with my connection, as I can download other files right now at 2Mb/s.
EDIT: Here it is: https://streamable.com/3ysv9
Gnus was too slow, but worse, emacs is single-threaded, so e.g. polling for new mail in the background blocked the rest of the editor while it happened. I never understood why it was impossible to have any kind of multithreading in emacs.
I'm working on a replacement for patchwork. Here's an example of a thread which was rendered with my tool, which is just generated from organic mail threads without extra human intervention:
If you have more feedback or thoughts around this, I'd love to hear it too :)
There are various ways to do multithreading in emacs now, but the answer to your question is usually “there’s a lot of existing elisp that isn’t thread-safe”, and that’s still kind of a problem.
But it is still easier to get fast code than in an obligate-functional language, because in the latter it is indefinitely hard to predict where such optimizations, where permitted, would actually happen; and in some cases they are not allowed anyway. The tradeoff is that in Lisp (as in other imperative languages) you have to do them yourself where you want them. But you can choose to do them only in hot paths, a tiny fraction of your code.
So far, Gnus is still the best mail client in a terminal (that you can have the same instance in a tty and a X11 environment is just a bonus).
Aerc looks interesting but then there's the ugly truth that I do much less mail than I used to do 10 years ago. So I probably won't switch even if it's looking really sexy.
Here are some screenshots, and here is a guide on how to set up mu4e.
Even spam or mails you want to delete before reading? There are dozens of mails I want to delete or put to the archive folder before reading, thus this feature is annoying me. And when I want to backup mail, I use offlineimap explicitly.
Besides, I use mu4e of 3 separate machines, and on each I have to keep a local copy of all my mails, even mails I've read already.
I love gnome, but on occasions I switch to KDE, where Konsole terminal has better Arabic support.
A while back, I engaged in epic combat against Apple Mail on my Mac, Apple's iOS mail app on my iPhone, Outlook on my Mac, Outlook on my gaming PC, Outlook on my Surface Pro 4, and Thunderbird on my Mac to banish the blight of, e.g., Sent, Sent Mail, and Sent Messages, and similar for drafts and deleted.
It was an epic struggle, but I finally got them to all agree on Sent, Trash, Drafts (and Junk for spam). I'm not going near any other email client now without being sure I can tell it to use those before I let it have access to my IMAP.
D = :mv Trash<Enter>
A = :mv Archive<Enter>
Thanks for all the hard work. Every year or so I try to switch my email workflow over to Mutt. I think I know what I’m trying this year!
(No, paying more attention is not a solution. People inevitably make these kinds of mistakes)
This problem comes up a lot if you have a client that wasn't set with English as the default language.
Just a small feedback: I had trouble with one of the requirements -> scdoc, didn't know what exactly that is (Googling didn't help), so might be worth to provide a direct link in the README.md to https://git.sr.ht/~sircmpwn/scdoc/
Also, I had to run it as:
panic: terminal entry not found
1. git clone https://git.sr.ht/~sircmpwn/scdoc
2. Edit Makefile and remove -static flag from ldflags
3. make install
4. git clone https://git.sr.ht/~sircmpwn/aerc
5. make install
You will need Go 1.12
Awesome work on aerc, looking forward for continued development.
(base) eximius@eximius-nuc:~/go/src/aerc-0.1.0$ apt-cache search scdoc
package git.sr.ht/~sircmpwn/aerc/commands: unrecognized import path "git.sr.ht/~sircmpwn/aerc/commands" (parse https://git.sr.ht/~sircmpwn/aerc/commands?go-get=1: no go-import meta tags ())
You need go 1.12.
aerc isn't quite as colorful or well-laid-out as Mutt but this is very promising.
This reminds me a lot of my all-time favorite mail editor, which I miss dearly: GoldED  
 https://blog.onlime.ru/wp-content/uploads/2018/12/CwkTcNSWQA... (Russian screenshot but you get the idea)
Irssi's default color scheme which, incidentally, is the same as Mutt's default. Both can be changed. For example, to a solarized color scheme.
Further, all rsync.net employees use pine for all rsync.net email. One interesting side-effect of this is that employee to employee emails are simply a local copy operation - they never traverse a network.
If you're looking into a mailtool that can run in the terminal (like this, or like mutt or (al)pine) I encourage you to consider running that mailtool on the actual machine with your mailspool. It allows your email to show up in your INBOX immediately and, as described above, allows for email interactions that don't leave the server ...
Months after i started using it, someone suggested i try mutt. I'm definitely going to, but i haven't got round to it yet.
What is the problem with Mutt though? Does Aerc have color or themeing support? Does it have a seperate daemon to talk the email protocols such as IMAP4?
This has to be a common problem. Are there any libraries, projects, email clients or scripts to help parse it all into something readable? I've looked and haven't found zip. I know Slack is the new hotness, but for the rest of us stuck in email, this is a daily hell. The progress of email clients basically stopped in the mid-2000s.
I swear, the first email client that actually solves this problem will be the next billion dollar business.
How's the GPG and S/MIME support? We'd really need an e-mail client that has first class support of both. Current solutions I've tried are cumbersome at best.
Having those two it'd actually be the best e-mail client for me.
First-class PGP support is planned and a blocker for 1.0, but not there yet. Here's a mockup to tease you:
Is PGP key discovery based on email planned/welcome? I'm talking about Web Key Directory introduced by GnuPG , being standardized by IETF  and already used by kernel.org , gentoo.org and others. GUI e-mail clients such as Enigmail or Mailpile support it but there is not CLI client with WKD.
hard pass on this as it encourages dark patterns.
It's stupid anyways to rely on never having UTF-8 because most clients do it to the extent of making lookalikes possible, but not so that it's usable for internationalized e-mails. If anything, e-mail clients should have built-in warning against such attacks as well as you using proper methods of determining who you're e-mailing.
* no good way to search/auto-complete addresses (I used vdirsyncer which got me the address book locally but there was no easy way to fill-in addresses when typing an email).
* no way to accept calendar requests - I would pull them up on my phone to accept or reject.
Otherwise, everything worked quite well, but those issues annoying enough that I eventually switched back to a Windows machine with Outlook. The Email+Calendar+Addressbook integration may violate the Linux philosophy of doing one thing well, but for today's typical office workflow it is frustrating not to have a platform with all three integrated.
I have it setup so I can use thunderbird for all my exchange interaction (except group management).
And also if you've looked at jmap? It's my distinct impression that the jmap effort isn't a case of nih, but rather stems from a real need of avoiding imap limitations (in idle, various levels of extension support).
One of my project ideas, for a long time, has been to figure out if dbmail might be tricked into being a decent jmap server via a graphql(like) proxy on top of postgres...
Neither handle syncing, so I use vdirsyncer for that (you can use anything you like or just go local only).
MineTime looks cool, but I got a wrong feeling about the looks and yeah, scrolling down and I saw it: "MineTime is a calendar built on Electron". Nah, I prefer to have just one browser open (and not Chrome/Chromium).
- a way to have all accounts in the same tab, with a unified inbox
- threading support, ideally with folding
https://github.com/leahneukirchen/mblaze - As the author says, "Unix utilities to deal with maildir".
https://github.com/aligrudi/neatmail - A noninteractive client with ex-like commands
http://plan9.stanleylieber.com/mother/ - for Plan9 people.
Based on a quick stroll through the source code, I don't see any search integration. Is that correct?
I guess I could just shell out to notmuch? But I do find virtual folders for searches really convenient. Currently using neomutt with notmuch support, over a Maildir (which in turn is separately synced via IMAP using mbsync).
Not having all the context vanish ala mutt would sure be nice.
No indirection through mbsync & maildir. This shouldn't be terribly hard - if you're interested in working on this feature, swing by the IRC channel to get a rundown of the technical details.
There's also a ticket for search in general:
Which will probably be implemented for IMAP by 0.2.0.
I personally work offline for a fair bit (personally more productive that way, and I'm also traveling plenty for work). So I kinda like the mbsync & maildir indirection (although I do hate the lack of NOTIFY, and some other imap inefficiencies around not supporting QRESYNC etc).
i'll be keeping an eye on it.
How does this compare to sup / mutt / alpine / astroid ?
Besides being light weight it's got some good features for an older client, it's GPL and can use plug-ins for extra functionality.
Nothing to do with he project, just a previously happy user.
1. It doesn't seem to work with when $TERM is set to some non-default setting. (panic: terminal entry not found)
2. When term is forced to xterm-256-color, aerc crashes when the window is resized.
grep -R maildir of the code returns nothing.
So I guess, using it on local mail is a no go. Sad. I tried it only because this was advertised, only to be disappointed.
It's better to not advertise features you don't have. Or at least state what features you have instead of mixing what you have and have not into a feature list at random.
It's also far cry from the configurability of the mutt/neomutt. But that can change. It would certainly be nice to have a properly scriptable terminal based MUA, as neomutt, while nice, and flexible, is kind of hard to configure.
Here's the ticket for maildir support:
Several people have expressed interest in working on this, I expect we'll see it for 0.2.0.
As far as configurability is concerned, yeah, the plan is to continue making it more customizable and configurable. Stuff like filters already afford you a lot of options today. At some point I might also be interested in adding a fifo you can use to feed commands into it from a script, too, for turing-complete customization.
I still think it's better to split the list into what is completed and roadmap. It would help me track the progress.
Anyway, good luck. I'll keep my eye on the project, because it certainly seems interesting.
If you would like to keep track of specific features, check out the bug tracker:
I found out reading this comment that not only it has a todo page but it works great! Not sure if it's a design choice but perhaps making the resources accessible in a single page (e.g. like a project home) would be something worth of consideration.
I have no interest in first-class exchange support upstream.
Better to avoid gmail.
Applications can always implement OAuth 2.0, which is pretty open (and is what you'll need to do for other mail providers, not just gmail.)
To make matters worse they falsely point the blame at competitors and then people like you defend them.
My suggestion will be to clean your mailbox instead of finding a new client.
I recall times (mid 2000's) when I was active in a bunch of open-source communities and mailing lists were the main way to discuss. Getting around 50 e-mail per day was normal.
I kept a lot of those discussions in my e-mail client for later reference, because the mailing list website had sub-par search function compared to Mozilla e-mail client I used at the time.
It's possible he's using it as an e-mail archive for mailing lists or something like that.
Some of that is mailing lists for sure, I'd say I respond to about ten direct emails (not from lists) per day. If I could use SMTP for IM, I'd probably do that too.
That seems interesting, I'll look at that. If there's one thing I have, it is a lot of memory. I would be okay if my whole Maildir was mmapped, as long as that made gnus faster.
I think using maildir directly may be hard to squeeze good performance out of with emacs. I'd suggest trying the alternatives: for eample, IMAP with ~30k messages should work decently in Wanderlust (and I would assume gnus), though initial load is slow (way less than hours, though). Using mu (maildir utils) via search in wanderlust to load 30k messages take about 1 minute, but if you are using mu you should be searching, not loading an entire mailbox. So there are probably some options out there, but I'd avoid loading 40k messages from a maildir directly.
Aerc is very new and written in Go. I tested it on my 100 thousnand mail ARM linux mailing list archive, accessed via localhost dovecot IMAP server, to see the best case performance, but it doesn't look good, atm.
It looks like this when I scroll through the archive: https://megous.com/dl/tmp/cjitwkaxpsypgcfdvncr.mp4
It's not really comparable to mutt, yet. The performance is slow, and it doesn't support threads, which is a must for MUA.
Yes, aerc is not yet as featureful or mature as mutt, but it definitely does not have inferior performance.
But yeah, I don't know about mutt IMAP performance, as I never used it. I've only configured a local IMAP server over my maildir to be able to try aerc. I have no clue why aerc is taking 100-200ms to load a single message (as you see in the video) from the localhost. Maybe naggle (is it even used on localhost)?
Also, I'm not sure how you'd make threads work while loading message list only partially. So full load of the message list is needed anyway (at least once and cache it locally). It's not some failing. I want thread that started 5 months ago to pop forward if new message is posted to it.
EDIT: Faster scrolling loads multiple messages at once faster. Maybe aerc can take into account that user may have scrolled past more than one message in the time the previous message finished loading.
aerc will also support maildir before 1.0, which doesn't have the same issue, and will be at least as fast as mutt.
>Also, I'm not sure how you'd make threads work while loading message list only partially. So full load of the message list is needed anyway (at least once and cache it locally). It's not some failing. I want thread that started 5 months ago to pop forward if new message is posted to it.
IMAP has a thread extension I intend to put to good use for this purpose.
I didn't know. Very nice.
- Attachments that don't have a filter can't be visualized. For this case would be interesting to open with 'xdg-open' when hit <Enter>, and/or '.mailcap' support.
- Account password is stored in plaintext
- Occasional rendering artifacts when switching tabs/folders
If those above are fixed plus theming, unread, etc. I can easily see myself using it as my daily driver.
You can use :save or :pipe on these, but yeah - xdg-open would also be cool. Mailcap support would also be great.
>Account password is stored in plaintext
In a chmod 600 file, though. There's also an option for configuring a command to run to retrieve your password by e.g. decrypting it with gpg: see aerc-imap(5), or :help imap, for details.
Seems like a good patch to implement a command that saves to a temporary file and opens with provided program, will certainly follow development, great work!
Makes me think what would email client designed for and integrated with tmux look like, i.e. the client would open new tmux panes for editors etc.
 don't take that as a hard criticism, I happen to think lot of things, especially around terminals, being hacks.
After following the README: this is clearly not ready/designed for wide consumption - the recipe neglects to mention how to install a custom doc-tool called scdoc (by the same author?) that is required to build it - and there are no pre-built binaries (that I can see).
It's not designed to be installed from pre-built binaries. It requires some other stuff to be set up on your system, too. It's designed to be friendly for distros to package instead. If you want to install it from source, use the Makefile like everything else.
> This repository is abandoned in favor of ongoing development on git.sr.ht. The codebase has been rewritten in Go and is much more stable and useful than what you see here.
@Sir_Cmpwn what's the advantage of git.sr.ht over github?
It's entirely open source (unlike GitHub), has its own CI, and is mailing list oriented instead of PR oriented.
Now maybe I'm just blind but I can't see a way to highlight unread emails in any way. Once I can get this working I'll switch in a heartbeat.
Workable alternatives are to store the decryption key in memory for the runtime of the program (eg. using login keyrings or per-app logic).
If you encrypt your $HOME or your entire disk, storing it in plain text achieves roughly the same level of protection (eg. decryption key is in the memory).
I can use mutt with emacsclient as my editor, in tmux.
You can't skip-through videos to get to the part you care about which is obvious in a textual format (and it's obvious if it's even there). You can't copy and paste stuff. You usually have to have sound on to understand what's going on.
Sorry for ranting a bit about this modern tendency to record videos instead of write text :)
I appreciate the suggestion, but unfortunately that's not even remotely adequate.
By integration I mean exposing every single function and UI element of the client to Emacs, so that they can be bound, wrapped and extended as needed. Ideally, these functions would be written in eLisp, so they themselves could be modified and customized to taste while leveraging the enormous Emacs eLisp ecosystem.
Emacs email clients have this sort of integration, and it is what gives them tremendous flexibility and power.
gnus is not the only way to do email in Emacs. IME, it is the most bloated way to do it.
While I didn't like the tone of the person's comment, I do sympathize with him. I used various email programs (pine, mutt, Thunderbird, etc) for years - but all of them seemed to lack something, and the effort to add my desired features was too high. With Emacs, the barrier to customize my workflow is a lot lower. Now that I've been using Emacs + notmuch for mail for the last few years, it's really hard to motivate myself to try anything outside Emacs, and the feeling is much worse when it's something cool like this.
I even haven't bothered with alot, although it is notmuch based. I mean, is it trivial for me to make an Org mode TODO linking to an email while in alot?