How's the UTF-8 e-mail address support? As most clients suck so bad at that it would be awesome to have an alternative.
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.
I was about to ask about PGP support too so thanks for the screenshots, they look great!
Is PGP key discovery based on email planned/welcome? I'm talking about Web Key Directory introduced by GnuPG [0], being standardized by IETF [1] and already used by kernel.org [2], gentoo.org and others. GUI e-mail clients such as Enigmail or Mailpile support it but there is not CLI client with WKD.
I think he is thinking about that some letters look identical but are encoded differently. So someone will not be able to look at an email address and say: oh it’s from such and such.
That's a side-effect of UTF-8, yes, but my primary concern was indeed non-English e-mail addresses, people should have the right to use their own names. You have GPG for identity validation though.
It's not like your mom without UTF-8 and without GPG is protected against phishing either. UTF-8 lookalikes are only a teeny-tiny fraction of any phishing.
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.
What about integrating emacs into aerc? You can set your EDITOR to emacs and replace aerc's default keybindings with a more emacs-inspired set. Send me your binds.conf and I'll add it to contrib in case anyone else wants an emacs-esque setup, too!
"You can set your EDITOR to emacs and replace aerc's default keybindings with a more emacs-inspired set."
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.
You can also say that Gnus is slow, if you want to be extra cheeky. As currently configured, opening gnus on my (admittedly a bit large) Maildir takes more than an hour (no, really, I'm not joking); of course, once it's up I dare not close it, and that works out fine for me.
>You can also say that Gnus is slow, if you want to be extra cheeky.
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?
Love the idea, and I really will give this a go as a daily driver.
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/
scdoc is probably available in your Linux distro's package manager, and aerc is designed to be packager-friendly - so eventually the idea is that most users will apt install aerc, rather than build it themselves.
This issue comes from tcell, which has a baked-in terminfo database. I'm also not sure about the state of the terminfo database in general on OSX... in any case, I plan on improving terminfo support in tcell at some point.
Thank you, I had the same problem. Apt couldn't find it in my Ubuntu 18.04.2 LTS install, and when I googled it I'm pretty sure "South Carolina Department of Corrections" wasn't what I was looking for. ;) So, thank you for the link.
It can't do maildir. I tried mdir:/// maildir:/// file:/// and /.
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.
There's a big red disclaimer on this page that says the feature list is a bit wishful, and the latest version is only 0.1.0. The docs (man pages, start with man aerc) only document implemented features, you may want to start there.
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 was looking at the git page and wondering where I could see discussion on features/bugs etc, I did not find it and was a bit frustrated.
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.
My least favorite email begins with a +Russell at the top, meaning that there's been a long email thread that I haven't been a part of, and now I've been pulled in. The text below that is your standard mess of email text: 1) It's in reverse chronological order starting at the bottom. 2) Each message has 4 or 5 lines of "to", "from", "cc", "subject" and "date" in between. 3) Previous messages might or might not be repeated by other email clients 4) All with varying levels of indenting.
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.
This is definitely already a solved problem - for open or homogeneous platforms. This is why it's still an issue for everyone else... Microsoft's general attitude is, "everyone should use Outlook", Apple wants you to use Mail, Google wants everyone on Gmail, etc. I'm sure this is rarely an issue inside those companies - threading "just works" since coworkers all use the same clients. So not only do they have zero financial reason to support interop or openness, they probably don't even know its an issue.
I dunno what it is about the screencast, but it takes _forever_ to load. Any chance you could upload to Youtube or something so that I can actually watch the thing?
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.
Native player in Chrome doesn't seem to download videos in big enough chunks or doesn't buffer well enough for smooth playback in some cases. I've seen it several times myself.
Would be good to have a calendar client in terminal.
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).
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.
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 am looking forward to this. i am currently using supmua, the ancestor of notmuch, and i haven't been able to switch to any other notmuch based terminal client because their interfaces all felt inferior to sup. aerc is the first client i see that does the interface with multiple switchable screens right from the start. notmuch integration with the ability to keep virtual folders based on tags and on searches is the only thing keeping me from trying out aerc right now.
You should have a look at astroid (https://github.com/astroidmail/astroid). It is written by one of the ex-maintainers of sup but uses notmuch, so the workflows are mostly similar. It's not in a terminal though.
Mutt/Neomutt is much more mature and has more features and better performance. (fantastic threads support, fast and very flexible filtering, etc.)
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.
aerc doesn't download all of your message headers upfront - mutt does. All that time you spend waiting for mutt to open your inbox is downloading all of the data that aerc is downloading as you scroll. Also, you can scroll faster with ^d/^u, half a page at a time, or pgup/pgdown, for a full page at a time.
Yes, aerc is not yet as featureful or mature as mutt, but it definitely does not have inferior performance.
I use POP3, and only wait for mutt when changing to a folder (4s/100k mails). Then everything is basically instantaneous.
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.
I'm guessing the main problem is that I can't cancel an IMAP request once it goes out. When you scroll down, one at a time, through all of the messages like that, I have to wait for ones that scrolled offscreen long ago before I can read out the details for the ones onscreen now. Adding an option to fetch all headers when opening a folder might be wise, or just fetching the offscreen headers in the background while idle. Another thing some email clients do is open several IMAP connections, but pooling connections to implement cancellation could get icky.
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.
- 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.
>Attachments that don't have a filter can't be visualized
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.
It seems ':pipe' sends the data to stdin, I was trying to see a pdf file and the programs I tried (evince, mupdf) do not seem to support this (or perhaps usage is different?).
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!
Gnus has been great for me, but after about 40k+ (I stopped looking at the counts actually) messages in my Maildir, performance suffers for me (that is, if I start gnus from scratch it takes more than an hour and a half to open, with my entire Maildir in the page cache, and a huge amount of extremely fast memory). Notmuch doesn't seem to help at all, or if it would, it's hard to tell if it's configured correctly.
That's a little odd -- I was using gnus with maildirs that size ten years ago and it wasn't so bad. nnmaildir backend for gnus, right? I remember something about increasing the emacs memory limit before garbage collection kicks in, too.
> I remember something about increasing the emacs memory limit before garbage collection kicks in, 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 have used Wanderlust on emacs for about 15 years now.)
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.
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.
Seems the number has also doubled. This Maildir starts about eight years ago IIRC, and there are now ~110k messages in it.
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.
40k/year (or 110/day) is nothing when you are active on mailing lists (yes, some of us still use them). Rule of thumb was "when you hit 1000/day, consider unsubscribing some..".
I wonder how good it is with wide width characters (in CJK languages). Handling them in a terminal is rather tricky, and I haven't seen anything that's good except ones that are developed by the actual users of the language.
I also think it is really only your terminal and fonts that have a say at how wide characters are handled (as well as Xresources if you run GNU/Linux). If you are on Linux a modern terminal emulator with great capabilities is kovidgoyal/kitty at Github.
Set TERM=xterm and try again. tcell (the library aerc uses to render its UI) has a really annoying built-in terminfo database, which at some point I plan on fixing myself.
Hmmm, I'm not familiar with command line email clients but this looks cool. I wonder if I can use aerc in a bash pipeline? Say, to pipe email content from/to gpg?
You can't pipe emails into aerc (yet?), but you can definitely pipe emails out of aerc. The :pipe command is bound to | by default, so you can type, for example, |gpg --decrypt | less<Enter>.
Neat! I used to be a kernel maintainer, and had a similar setup going inside emacs with gnus, and dvc-git commands bound to keys to apply patches. Here's an old blog post about some of it:
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.
Hey, would you mind writing up some details about your email setup for kernel work to sir@cmpwn.com? I'd like to understand more email-driven workflows, especially from kernel maintainers, to guide aerc's design.
Hm! I can't think of much to add, except.. the next thing I would've worked on might've been to integrate a client for https://patchwork.kernel.org/ to keep it in sync and mark patches there as handled.
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:
A Patchwork client (well, a tool that does some of the more useful patchwork status updating, it's not a full client as such) for notmuch, which has a number of kernel dev users: https://github.com/stewart-ibm/pwnm-sync
> I never understood why it was impossible to have any kind of multithreading in emacs.
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.
I’m still a novice functional programmer so this may be a dumb comment but I thought a lisp would be more thread safe due to immutable data structures.
Not all fp languages are purely functional, and certainly not all lisps. In fact, the only lisp that I'm aware of that focuses on immutability is clojure. Granted, many lisp programmers may decide to keep their functions pure, but it's rarely enforced.
Lisp is not a functional language. Or, not an obligate-functional language. I.e. you can do functional if you like, but where it becomes a PITA, you can just assign. Because of that, many optimizations possible in obligate-functional languages are not safe. Because of that, you sometimes need to do your own such optimizations, non-functional-wise.
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.
I "solved" this by having a separate emacs instance where I'd do mail and usenet.
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.
271 comments
[ 2.8 ms ] story [ 299 ms ] threadBut 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 have no interest in first-class exchange support upstream.
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:
https://cmpwn.com/system/media_attachments/files/000/351/218...
https://cmpwn.com/system/media_attachments/files/000/351/219...
Is PGP key discovery based on email planned/welcome? I'm talking about Web Key Directory introduced by GnuPG [0], being standardized by IETF [1] and already used by kernel.org [2], gentoo.org and others. GUI e-mail clients such as Enigmail or Mailpile support it but there is not CLI client with WKD.
[0]: https://wiki.gnupg.org/WKD
[1]: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
[2]: https://www.kernel.org/category/signatures.html#using-the-we...
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.
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?
Even Emacs.
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:
On OSX, otherwise got:Awesome work on aerc, looking forward for continued development.
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
You need go 1.12.
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:
https://todo.sr.ht/~sircmpwn/aerc2/16
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:
https://todo.sr.ht/~sircmpwn/aerc2
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.
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.
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
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).
Neither handle syncing, so I use vdirsyncer for that (you can use anything you like or just go local only).
https://github.com/scheibler/khard
https://github.com/pimutils/khal
https://github.com/pimutils/vdirsyncer
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.
https://todo.sr.ht/~sircmpwn/aerc2/105
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:
https://todo.sr.ht/~sircmpwn/aerc2/93
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.
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!
:)
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.
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.
How does this compare to sup / mutt / alpine / astroid ?
https://blog.printf.net/articles/2010/10/04/git-patches-in-g...
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.
https://sourcehut.org
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:
https://lists.sr.ht/~philmd/qemu/patches/5556
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.