Aerc: A well-crafted TUI for email(blog.sergeantbiggs.net)
blog.sergeantbiggs.net
Aerc: A well-crafted TUI for email
https://blog.sergeantbiggs.net/posts/aerc-a-well-crafted-tui-for-email/
165 comments
I'm interested in the Gmail integration. Tried it with mutt and decided I didn't want to spend an afternoon figuring it out.
'Sides, I hear that Gmail is phasing out IMAP. :-?
'Sides, I hear that Gmail is phasing out IMAP. :-?
For GMail sync someone else has already mentioned Lieer which is an excellent tool for robust two-way syncing of emails and tags/labels between Notmuch (and anything that uses it) and GMail. It uses the GMail API so it doesn't rely on IMAP.
https://github.com/gauteh/lieer
https://github.com/gauteh/lieer
> 'Sides, I hear that Gmail is phasing out IMAP. :-?
No, just unsecure access:
https://workspaceupdates.googleblog.com/2023/09/winding-down...
No, just unsecure access:
https://workspaceupdates.googleblog.com/2023/09/winding-down...
Can you point out which part of this is relevant to Gmail integration?
> 'Sides, I hear that Gmail is phasing out IMAP.
Nope. AFAIK, Microsoft is phasing out POP, and maybe GMail, but not IMAP.
If you're using two factor authentication, you need to use an App Password.
Nope. AFAIK, Microsoft is phasing out POP, and maybe GMail, but not IMAP.
If you're using two factor authentication, you need to use an App Password.
> If someone is interested, I will link my GitHub repo.
I'm very interested...this post has encouraged me to play with aerc again, and the first filter you posted is something I have always wanted in an email client!
I'm very interested...this post has encouraged me to play with aerc again, and the first filter you posted is something I have always wanted in an email client!
https://github.com/rafo/aerc-vim
- Added image preview of attachments
- Added image preview of attachments
I'm interested, specifically with the vim keybindings, which would make getting started with it much easier for me.
I have plumbed the depths of mutt, and I have discovered that, alas, graphical email clients fit my needs better.
- Mutt/aerc doesn't support windows, an OS many use by preference or requirement (though I have explored this with mutt[2], it's hard getting anything to work in mailcap on windows)
- Doesn't support viewing HTML email, a ubiquitous phenomenon
- Doesn't support sending HTML email, which is fine until your coworkers wonder why your mails always look funky and replies lose formatting
- I'm faster in Betterbird[1] than I am in mutt. Turns out drag-and-dropping mails into folders is pretty fast.
- Configuring an even halfway decent set-up takes ages, Betterbird just works out of the box
- Mutt relies on mbsync[3] or offlineimap[4], these tools don't support OAuth well. Betterbird supports it out of the box. (You can run without them, if you're willing to put up with bad buggy behavior in GMail where when messages are moved into folders they are only copied, the original message stays put in the original folder while a new message is copied into the other.)
- With shift+click, Betterbird allows the user to reply or compose using plain text just fine when the need arises
Sorry guys. I absolutely live in the terminal, but enough's enough. I'm out.
I do like using newsboat as an RSS reader though, that investment panned out so far.
1: https://www.betterbird.eu/
2: https://news.ycombinator.com/item?id=39812124
3: https://isync.sourceforge.io/mbsync.html
4: https://www.offlineimap.org/
- Mutt/aerc doesn't support windows, an OS many use by preference or requirement (though I have explored this with mutt[2], it's hard getting anything to work in mailcap on windows)
- Doesn't support viewing HTML email, a ubiquitous phenomenon
- Doesn't support sending HTML email, which is fine until your coworkers wonder why your mails always look funky and replies lose formatting
- I'm faster in Betterbird[1] than I am in mutt. Turns out drag-and-dropping mails into folders is pretty fast.
- Configuring an even halfway decent set-up takes ages, Betterbird just works out of the box
- Mutt relies on mbsync[3] or offlineimap[4], these tools don't support OAuth well. Betterbird supports it out of the box. (You can run without them, if you're willing to put up with bad buggy behavior in GMail where when messages are moved into folders they are only copied, the original message stays put in the original folder while a new message is copied into the other.)
- With shift+click, Betterbird allows the user to reply or compose using plain text just fine when the need arises
Sorry guys. I absolutely live in the terminal, but enough's enough. I'm out.
I do like using newsboat as an RSS reader though, that investment panned out so far.
1: https://www.betterbird.eu/
2: https://news.ycombinator.com/item?id=39812124
3: https://isync.sourceforge.io/mbsync.html
4: https://www.offlineimap.org/
Aerc:
Could probably be built on Windows. You just need Go and make. Betterbird supports MacOS only since a view weeks. My initial suggestions to build it for Mac was denied by the author because of „money“.
Let’s you view html emails. It’s in the article.
I bet moving mails by keystrokes are much faster than drag and drop per mouse. If you use the same folders again and again it even faster. Eg:
Works fine with OAUTH
BB is fine but I hate it that I can’t use my own keyboard shortcuts. A ubiquitous phenomenon.
Could probably be built on Windows. You just need Go and make. Betterbird supports MacOS only since a view weeks. My initial suggestions to build it for Mac was denied by the author because of „money“.
Let’s you view html emails. It’s in the article.
I bet moving mails by keystrokes are much faster than drag and drop per mouse. If you use the same folders again and again it even faster. Eg:
pa = :archive flat<Enter> # move (think put or paste) mail in the archive folder
pb = :move<space> Brain<Enter> # move mail in my Brain.
pf = :move<space> # move (think put or paste) mail in folder. Next character filters folders.
Works fine with OAUTH
BB is fine but I hate it that I can’t use my own keyboard shortcuts. A ubiquitous phenomenon.
All fair points. The second and third one can be mitigated by a, say, w3m mailcap entry respectively muttrc entry set send_multipart_alternative_filter=markdown2html.py [1]
[1] https://gitlab.com/muttmua/mutt/-/blob/master/contrib/markdo...
[1] https://gitlab.com/muttmua/mutt/-/blob/master/contrib/markdo...
"Mutt/aerc doesn't support windows, an OS many use by preference or requirement"
All modern Windows boxes have Hyper-V built in to some extent and you can run a Linux VM. You have OpenSSH natively too. It will take a bit of twiddling to setup a suitable environment but not much.
I use Linux exclusively and prefer GUIs too. I use Evolution against MS Exchange on-prem, for my sins. I also run a set of vanity email domains for friends and family (Dovecot, Exim etc).
I'm not familiar with Betterbird but it is now bookmarked and noted for eval.
One day we are going to have to dump the Exchange box and I look forward to the discussion about what happens next. M365? Nope, or OK - you kids do that and I'll bugger off and do my own thing. Do bear in mind that I've been running the email system for 25+ years (it was GroupWise once) and I am the Managing Director!
In the end you really can replace Exchange with and IMAPD, MTA etc and a calendaring app of some sort.
Anyway, I'm strolling rather rapidly off topic. Sorry and thanks for the Betterbird notes.
All modern Windows boxes have Hyper-V built in to some extent and you can run a Linux VM. You have OpenSSH natively too. It will take a bit of twiddling to setup a suitable environment but not much.
I use Linux exclusively and prefer GUIs too. I use Evolution against MS Exchange on-prem, for my sins. I also run a set of vanity email domains for friends and family (Dovecot, Exim etc).
I'm not familiar with Betterbird but it is now bookmarked and noted for eval.
One day we are going to have to dump the Exchange box and I look forward to the discussion about what happens next. M365? Nope, or OK - you kids do that and I'll bugger off and do my own thing. Do bear in mind that I've been running the email system for 25+ years (it was GroupWise once) and I am the Managing Director!
In the end you really can replace Exchange with and IMAPD, MTA etc and a calendaring app of some sort.
Anyway, I'm strolling rather rapidly off topic. Sorry and thanks for the Betterbird notes.
Maybe dodo[1] is something for you. It is basically a graphical email client but with lots of vim-bindings.
Basically the best of both worlds, terminal and graphical. Like the qutebrowser[2] for emails.
However I think its kinda in a unmaintained state and only supports notmuch backend.
1: https://github.com/akissinger/dodo 2: https://qutebrowser.org/
Basically the best of both worlds, terminal and graphical. Like the qutebrowser[2] for emails.
However I think its kinda in a unmaintained state and only supports notmuch backend.
1: https://github.com/akissinger/dodo 2: https://qutebrowser.org/
qutebrowser author here, use Dodo and can confirm it's basically the qutebrowser of mail clients :)
Development is slow but not unmaintained. The author comes back every month or so to merge PRs. Reminds me I have a bunch of local changes I should upstream...
Development is slow but not unmaintained. The author comes back every month or so to merge PRs. Reminds me I have a bunch of local changes I should upstream...
I stumbled upon Dodo while checking your starred repos, and I think it deserves more attention than it has; it is mature enough to be used by users who wants customizibility, vim-bindings, and easy configuration. It's one of my top options to migrate to as a mail client if I find any problems with neomutt, which I am using right now.
despite the questionable politics of the author, I use mutt-wizard, and using its configs, a simple "v" instead of "o" will open the mail in the open web-browser. I've found this more than acceptable for reading html mail.
I don't use it for work, only personal use, though, so ymmv.
I don't use it for work, only personal use, though, so ymmv.
Do you feel like you shouldn't use it because of the author's politics? It's not like he gains anything from you using it. Even if he gained money from it I don't think there's any reason to believe he'd use that money to further those political opinions.
I got sick of having five different GMail tabs open (and two non-GMail mail tabs open), so I have been setting up aerc this week, using the Notmuch backend and either lieer (for GMail) or mbsync (for non-GMail) to sync the mail.
Its taken maybe a dozen hours to get it set up and get into the flow, but I find it much, much more enjoyable than my previous workflow. Plus, though GMail tabs each took a 100+ MB of memory in Firefox, the new setup is much less heavyweight, and the local search is speedy and high quality.
Its taken maybe a dozen hours to get it set up and get into the flow, but I find it much, much more enjoyable than my previous workflow. Plus, though GMail tabs each took a 100+ MB of memory in Firefox, the new setup is much less heavyweight, and the local search is speedy and high quality.
If you are using Notmuch, I recommend trying bower[1]. It is a TUI for interacting with notmuch, and can even be configured to do so over ssh, so that e.g. opening attachments can happen on your local machine, even if your notmuch db is on a different computer.
1: https://github.com/wangp/bower
1: https://github.com/wangp/bower
> so I have been setting up aerc this week, using the Notmuch backend
I strongly urge people to try notmuch. I switched to it in around 2011 and have never gone back.
You don't have to use Emacs as the client. There are plenty of other frontends (including aerc).
https://notmuchmail.org/frontends/
alot[1] is probably the most well known among them:
https://github.com/pazz/alot
I strongly urge people to try notmuch. I switched to it in around 2011 and have never gone back.
You don't have to use Emacs as the client. There are plenty of other frontends (including aerc).
https://notmuchmail.org/frontends/
alot[1] is probably the most well known among them:
https://github.com/pazz/alot
Looks really neat. Thanks.
What do you use to sync your Gmail to local for notmuch to index?
What do you use to sync your Gmail to local for notmuch to index?
I don't use Gmail :-)
You could use something like lieer[1] which will also sync your notmuch tags with gmail labels.
If you don't want to sync the labels, I'm sure there are plenty of solutions out there to download Gmail to your local machine in a well known format like Maildir.
[1] https://github.com/gauteh/lieer
You could use something like lieer[1] which will also sync your notmuch tags with gmail labels.
If you don't want to sync the labels, I'm sure there are plenty of solutions out there to download Gmail to your local machine in a well known format like Maildir.
[1] https://github.com/gauteh/lieer
Thank you
While tui mail clients always seemed appealing to me, I think I realized why something in me resists them.
The terminal is my "meditation space"; it's where I go when I want to focus deeply and do real and work that I enjoy; my playground.
Viewing or writing emails is a chore, just like Slack. I don't want that iny terminal.
The terminal is my "meditation space"; it's where I go when I want to focus deeply and do real and work that I enjoy; my playground.
Viewing or writing emails is a chore, just like Slack. I don't want that iny terminal.
I see this a bit differently. It’s exactly because some tasks feel like a chore that I gravitate to tools that improve the experience.
To me, keeping these tasks separate is just reinforcing the negative association those tasks have built up over time in my brain. The degree to which they continue sucking has as much to do with my own thinking about the tasks as the tasks themselves. I’d rather find ways to make the suckiest tasks even a tiny bit more palatable, and at least in my case, don’t find that this impacts the things I love about working in the terminal in any way.
At the end of the day, I’m going to have to tackle all of it eventually. Might as well make it easier on myself. YMMV.
To me, keeping these tasks separate is just reinforcing the negative association those tasks have built up over time in my brain. The degree to which they continue sucking has as much to do with my own thinking about the tasks as the tasks themselves. I’d rather find ways to make the suckiest tasks even a tiny bit more palatable, and at least in my case, don’t find that this impacts the things I love about working in the terminal in any way.
At the end of the day, I’m going to have to tackle all of it eventually. Might as well make it easier on myself. YMMV.
This is enlightening. I prefer to lean heavily on my terminal for most things, but tui email + web browsing never quite "clicked" for me. And I feel like this perfectly encapsulates why. Thanks for putting words to the feeling!
The issues we humans have with emails in the present time lay in the lack of modern PERSONAL email tools development.
For modern and personal I mean NOT living on someone else mailserver but easily download or sync remote IMAPs, or to use them directly (with some issues [1]) or via a personal homeserver IMAP, with a modern search-based client like notmuch-emacs/mu4e, and a built-in decent filtering tool (like MailDrop).
We have essentially all the pieces (we can use IMAPFilter + OfflineIMAP to refile messages if we just sync them, or the old fetchmail + MailDrop if we download, using notmuch in Emacs or with also Aerc) but they are different software with different configs, styles, variable level of documentation and userfriendliness etc. There is NOTHING for less geek/expert users a thing that makes many considering email == webmails and so a webmail is a service by a third party (for such users) as is Slack, WhatsApp web and so on, a dangerous vision for the freedom of communication and the power emails offer.
I hope some think about that enough to makes thing changes not only at geek levels... It's not that hard having a MailDrop rule that match an ISP regular bill launching a script that add the due date, amount to an agenda, than check the local accounting software for relevant transaction presence and warn if something it's not as expects, not that hard with text-based tools, like org-agenda, BeanCount, MailDrop, emails. VERY hard with modern software and that's a big loss for many potential power users who can't profit of such easy automation simply because for them it's too long to learn and implement and often even an unknown option. IT was born to simply life and augment human cognition, it's very sad almost all have forgotten that.
[1] due to mail files naming syncing on multiple machines often create unread/tags annoyances, with duplicate messages generation and so on...
For modern and personal I mean NOT living on someone else mailserver but easily download or sync remote IMAPs, or to use them directly (with some issues [1]) or via a personal homeserver IMAP, with a modern search-based client like notmuch-emacs/mu4e, and a built-in decent filtering tool (like MailDrop).
We have essentially all the pieces (we can use IMAPFilter + OfflineIMAP to refile messages if we just sync them, or the old fetchmail + MailDrop if we download, using notmuch in Emacs or with also Aerc) but they are different software with different configs, styles, variable level of documentation and userfriendliness etc. There is NOTHING for less geek/expert users a thing that makes many considering email == webmails and so a webmail is a service by a third party (for such users) as is Slack, WhatsApp web and so on, a dangerous vision for the freedom of communication and the power emails offer.
I hope some think about that enough to makes thing changes not only at geek levels... It's not that hard having a MailDrop rule that match an ISP regular bill launching a script that add the due date, amount to an agenda, than check the local accounting software for relevant transaction presence and warn if something it's not as expects, not that hard with text-based tools, like org-agenda, BeanCount, MailDrop, emails. VERY hard with modern software and that's a big loss for many potential power users who can't profit of such easy automation simply because for them it's too long to learn and implement and often even an unknown option. IT was born to simply life and augment human cognition, it's very sad almost all have forgotten that.
[1] due to mail files naming syncing on multiple machines often create unread/tags annoyances, with duplicate messages generation and so on...
> modern PERSONAL email tools
The capitalized personal part there is so important! So few people today even realize what is possible, since they are captive in websites like gmail that have so very little functionality.
email was always supposed to have a 100% customizable workflow, filtering, sorting, foldering, etc.
We still have this of course, as all the old tools work. But there needs to be more awareness how great email is when used as originally intended. I'd despise email too if I believed gmail is email, but it's not.
procmail and mutt still work just fine!
The capitalized personal part there is so important! So few people today even realize what is possible, since they are captive in websites like gmail that have so very little functionality.
email was always supposed to have a 100% customizable workflow, filtering, sorting, foldering, etc.
We still have this of course, as all the old tools work. But there needs to be more awareness how great email is when used as originally intended. I'd despise email too if I believed gmail is email, but it's not.
procmail and mutt still work just fine!
I still use fetchmail, while I prefer MailDrop over procmail :-)
And, yes, I 110% agree about automation revolving around emails, or simply revolving around exchanging text between people asynchronously. I still have my ascii ribbon campaign in the signature [well, mostly because I very lazy].
One of the first kind of automation, it's just mere handling, I have auto-delete for some mails not flagged, to keep my maildirs of a human size, and having them on my iron I can choose both the size and how much allow to grow without having to pay extra subscription or experimenting many third party "old mails missing" issues. But also small potatoes automation from "the smart home", bills annotations and so on. If a sufficient mass of people know how much and how simply we can do certain things like extracting attachments (uudeview, ripmime etc) and archiving them we can easily imaging e-bills (now that most western countries have them, for those who do not know e-invoices, typically XML-based with signatures or not, sometimes pdfs with embedded XML/JSON) attached and automatically archived by our desktop for future access in a snap.
Similar things about other "old tools" from usenet to RSS, just imaging your bank offering an authenticated feed of every transaction, markets changes etc with push notifications as well.
With these tools the modern world could be automated 10x the actual level with 1/10 of the actual effort needed for just the actual level. Unfortunately those who know today are less and less and very unfortunately those teaching in academia seems to have lost any interest in teaching, maybe with some incentives by big tech...
And, yes, I 110% agree about automation revolving around emails, or simply revolving around exchanging text between people asynchronously. I still have my ascii ribbon campaign in the signature [well, mostly because I very lazy].
One of the first kind of automation, it's just mere handling, I have auto-delete for some mails not flagged, to keep my maildirs of a human size, and having them on my iron I can choose both the size and how much allow to grow without having to pay extra subscription or experimenting many third party "old mails missing" issues. But also small potatoes automation from "the smart home", bills annotations and so on. If a sufficient mass of people know how much and how simply we can do certain things like extracting attachments (uudeview, ripmime etc) and archiving them we can easily imaging e-bills (now that most western countries have them, for those who do not know e-invoices, typically XML-based with signatures or not, sometimes pdfs with embedded XML/JSON) attached and automatically archived by our desktop for future access in a snap.
Similar things about other "old tools" from usenet to RSS, just imaging your bank offering an authenticated feed of every transaction, markets changes etc with push notifications as well.
With these tools the modern world could be automated 10x the actual level with 1/10 of the actual effort needed for just the actual level. Unfortunately those who know today are less and less and very unfortunately those teaching in academia seems to have lost any interest in teaching, maybe with some incentives by big tech...
> Similar things about other "old tools" from usenet to RSS, just imaging your bank offering an authenticated feed of every transaction, markets changes etc with push notifications as well.
What a dream that would be!
Agree with everything above. In the 90s everything was trivially easy to automate and customize in any way one wanted. As the world has moved to ever more isolated siloed webapps that barely have any functionality built-in (which makes sense since every feature has to be built as a one-off addition to that specific website) and don't hook into or interoperate with any tools, we keep moving ever backwards in functionality and automatability.
This is not the future that was supposed to be.
What a dream that would be!
Agree with everything above. In the 90s everything was trivially easy to automate and customize in any way one wanted. As the world has moved to ever more isolated siloed webapps that barely have any functionality built-in (which makes sense since every feature has to be built as a one-off addition to that specific website) and don't hook into or interoperate with any tools, we keep moving ever backwards in functionality and automatability.
This is not the future that was supposed to be.
> we keep moving ever backwards
Sadly true, but if you observe a larger timeframe:
- back to Unix time, unixers say GUIs are unneeded complexity, in very little time Unix add X, not like Smalltalk workstations, but still similar, one of the first based on the current 2D graphics for documents, SunWS, or DisplayPostscript server;
- back at first Windows time, Windowser say widget based GUIs are the sole GUI needed, and that last long, but, the web 2.0, QtQuick, ... state clearly no, we can't live on widgets, and we are now essentially back to a much more complex and not much more featuresful DisplayPostscript equivalent, still a kind of DocUI like the Xerox workstations ones, only NOT moldable by end users;
- at a smaller levels menus are mostly substituted with search&narrow tools, from the "classic desktop menu" to "the dash", Android preference with a quicksearch, equally present for apps menu, failed but very good Ubuntu Unity HUD, we can go till search engine and ML (LLM, mostly) prompts, all are "back" at users entering text instead of clicking around pre-made menus;
- decades after CanonCat notes are now very common even for not so power users, and notes pale and limited automation start to appear here and there (R with Quarto, where the user write a mix of data (MD) and code (R) to generate a pdf via pandoc/LaTeX (or something similar in their backend), to Zettlr note "export template" functionalities and so on, actually is the data and code of Lisp and Smalltalk systems back then, in users hands even if that part is sometimes a bit hidden.
Long story short good ideas came back, generally only after an immense amount of time and turned into Greenspun's tenth rule bug-ridden, half-backed soups, but still they are back. So well... As the time passes "digitalization" happen and some start to think, rediscovering old concepts often not knowing they are old, but still came back. Maybe in 50+ the future web will be composed of feeds, full articles in the feed, and the same mechanism will be used for releases announcements, bug tracking, vulnerability notice and so on, as well as something equivalent of emails, equally scriptable.
For me the sole key is not losing all the past memory, so we can know how bad evolution arrives and how they disappear to collect experience and a bit at a time correcting errors.
Reading history I think this same phenomenon happen in all fields, good stuff tend to die early en masses, only few survive often badly changed, but a bit at a time died early stuff came back. Sad for the humanity, sad for those who know but at least still good for future generations.
Sadly true, but if you observe a larger timeframe:
- back to Unix time, unixers say GUIs are unneeded complexity, in very little time Unix add X, not like Smalltalk workstations, but still similar, one of the first based on the current 2D graphics for documents, SunWS, or DisplayPostscript server;
- back at first Windows time, Windowser say widget based GUIs are the sole GUI needed, and that last long, but, the web 2.0, QtQuick, ... state clearly no, we can't live on widgets, and we are now essentially back to a much more complex and not much more featuresful DisplayPostscript equivalent, still a kind of DocUI like the Xerox workstations ones, only NOT moldable by end users;
- at a smaller levels menus are mostly substituted with search&narrow tools, from the "classic desktop menu" to "the dash", Android preference with a quicksearch, equally present for apps menu, failed but very good Ubuntu Unity HUD, we can go till search engine and ML (LLM, mostly) prompts, all are "back" at users entering text instead of clicking around pre-made menus;
- decades after CanonCat notes are now very common even for not so power users, and notes pale and limited automation start to appear here and there (R with Quarto, where the user write a mix of data (MD) and code (R) to generate a pdf via pandoc/LaTeX (or something similar in their backend), to Zettlr note "export template" functionalities and so on, actually is the data and code of Lisp and Smalltalk systems back then, in users hands even if that part is sometimes a bit hidden.
Long story short good ideas came back, generally only after an immense amount of time and turned into Greenspun's tenth rule bug-ridden, half-backed soups, but still they are back. So well... As the time passes "digitalization" happen and some start to think, rediscovering old concepts often not knowing they are old, but still came back. Maybe in 50+ the future web will be composed of feeds, full articles in the feed, and the same mechanism will be used for releases announcements, bug tracking, vulnerability notice and so on, as well as something equivalent of emails, equally scriptable.
For me the sole key is not losing all the past memory, so we can know how bad evolution arrives and how they disappear to collect experience and a bit at a time correcting errors.
Reading history I think this same phenomenon happen in all fields, good stuff tend to die early en masses, only few survive often badly changed, but a bit at a time died early stuff came back. Sad for the humanity, sad for those who know but at least still good for future generations.
I love modern text based projects, really, thank you all for keeping the terminal alive and relevant.
I was watching this guy demonstrate using Emacs to read email with mu4e. He pipes the HTML directly to Firefox for viewing the HTML parts, and some others he converts to PDF to view them:
https://www.youtube.com/watch?v=1uulLBKBMX8
aerc is really weird in the sense of being designed as a client, not storing the mails on your computer. Which has some performance implications and limitations. Though you can have local mail too, really felt like a second-class feature when I looked. But to be fair it has been a long time since I looked at it.
Given the above I'm really surprised that IMAP doesn't work better than it does. Often gets disconnected and I have to restart to get back to it.
Also have trouble with shortcut overlapping in neovim and aerc.
All in all, not super happy. I could maybe give it a second chance and see what I've missed in my setup, but currently more hopeful about neomutt.
Given the above I'm really surprised that IMAP doesn't work better than it does. Often gets disconnected and I have to restart to get back to it.
Also have trouble with shortcut overlapping in neovim and aerc.
All in all, not super happy. I could maybe give it a second chance and see what I've missed in my setup, but currently more hopeful about neomutt.
Using it with local mail dirs is definitely preferable. I would assume that most people use mail TUIs in conjunction with `mbsync`, `notmuch`, and similar utilities that improve the overall experience.
>Given the above I'm really surprised that IMAP doesn't work better than it does. Often gets disconnected and I have to restart to get back to it.
Same happens to me. This is gonna sound scuffed, but I just started running aerc in a while loop and I hit q to quit if it's acting up, only takes a couple seconds to load back up. Still my favorite mail client, but could definitely be better.
Same happens to me. This is gonna sound scuffed, but I just started running aerc in a while loop and I hit q to quit if it's acting up, only takes a couple seconds to load back up. Still my favorite mail client, but could definitely be better.
> Also have trouble with shortcut overlapping in neovim and aerc.
I'm curious what you mean by this. Doesn't Vim use almost every key on the keyboard, so wouldn't this be a problem with pretty much any program?
I'm curious what you mean by this. Doesn't Vim use almost every key on the keyboard, so wouldn't this be a problem with pretty much any program?
Yeah not sure what OP meant, it has a "passthrough" mode for composing, basically every key combo is passed to the editor (Helix in my case, very similar to Vim), and control is returned to aerc when you close the editor
The best email user agent, mutt, reconnects automatically if the connection to your IMAP server fails (although this seems not to work every time):
https://lwn.net/Articles/837960/
https://lwn.net/Articles/837960/
> aerc is really weird in the sense of being designed as a client, not storing the mails on your computer.
Isn't that true for mutt as well?
Isn't that true for mutt as well?
If anything, I feel it's the other way around for Mutt. I've been using Mutt for at least 10 years using local mail storage almost exclusively that entire time, and I've never found it to be cumbersome. I tried IMAP at one point, and I was not a fan.
[deleted]
himalaya looks promising..
https://github.com/soywod/himalaya
https://pimalaya.org/himalaya/cli/latest/index.html
https://github.com/soywod/himalaya
https://pimalaya.org/himalaya/cli/latest/index.html
I don't see an explanation anywhere what "TUI" is. I'm going to go with "text user interface".
Terminal User Interface or Text-based User Interface
[deleted]
I would really love to try a terminal email client with html email parsing.
I miss pine.
I miss pine.
I used to use mutt and bind a keyboard shortcut to pipe HTML messages to w3m.
I miss Pine too. I could read/file/delete scores of plaintext emails in seconds using single keystrokes.
Every email client I've used since Pine has been better at dealing with all the stuff we've bolted on to email (HTML, attachments, calendar invites...) but none of them have been as efficient at the core tasks of email as Pine was.
Every email client I've used since Pine has been better at dealing with all the stuff we've bolted on to email (HTML, attachments, calendar invites...) but none of them have been as efficient at the core tasks of email as Pine was.
What sort of keystrokes? The Fastmail web interface uses single keystrokes for interacting with mail, which is very handy.
You could give my email client https://github.com/d99kris/nmail a shot. It does basic html email parsing (leveraging w3m and pandoc) and its user interface is inspired by pine.
mutt is alive and well, it's all I use for email.
At work I'm forced to use the unusable gmail website, ugh.
At work I'm forced to use the unusable gmail website, ugh.
Curious what's unusable about gmail. I love the UI plus I also love the sidebar with tasks, calendar, etc.
For me outlook is the real pain, I just redirect my emails there to my gmail.
For me outlook is the real pain, I just redirect my emails there to my gmail.
Gmail is not a real email client; it lacks basic commands such as mail bouncing. Perhaps worst of all, it has no concept of conversation threads, as I demonstrate here:
https://lwn.net/Articles/837960/
https://lwn.net/Articles/837960/
Huh that's really interesting. I have used mutt before, and I hated how it handled replies and that was the reason I returned to plain gmail.
I guess it's a matter of taste.
I guess it's a matter of taste.
You can parse html emails with it by piping to w3m or using pandoc
Pine is not dead for me yet. I use alpine as daily driver, although the releases are not that often.
I'm kind of locked in to Thunderbird as it manages decades of my mail.
I wonder if one could develop a decent TUI for Thunderbird / its database...
I wonder if one could develop a decent TUI for Thunderbird / its database...
I feel the same. I have "only" about 15 years worth of mail in Thunderbird but I am getting increasingly tired of working with the GUI, at least for reading and searching historical mail.
One of these days I will convert my mbox mail to Maildir and try out notmuch.
One of these days I will convert my mbox mail to Maildir and try out notmuch.
I switched to alpine (https://alpineapp.email/) after 20 years of thunderbird. Converting 20 years of archived thunderbird emails took a couple of minutes with a script I found somewhere, so now everything rests securely in the Maildir format.
I am quicker, happier and more efficient with TUI email than ever before, and as a bonus, the memory and CPU footprint is too small to see.
What is important though is to keep in mind that I am not a power user. At most I might get 200 emails per day or so, but for that work loads everything works brilliantly.
I have automated rules, shortcuts, I can define my own keys, I can even rewrite the source for smaller things if I want.
I recommend everyone to invest a day or two just to see if it is for you.
I am quicker, happier and more efficient with TUI email than ever before, and as a bonus, the memory and CPU footprint is too small to see.
What is important though is to keep in mind that I am not a power user. At most I might get 200 emails per day or so, but for that work loads everything works brilliantly.
I have automated rules, shortcuts, I can define my own keys, I can even rewrite the source for smaller things if I want.
I recommend everyone to invest a day or two just to see if it is for you.
The problem with a TUI is that it’s a silo. Makes more sense to have pipeable, scriptable program(s) to retrieve/filter/sync/send. Then you can make several different UIs for it—vim, emacs, web, vscode, acme, thick client, etc—with a minimum of effort. TUI ends up re-implementing a good part of tmux unnecessarily.
Composability is what I love about Notmuch: https://notmuchmail.org/
The Notmuch client is also really well done.
Notmuch (any perhaps mu) is perhaps the silver bullet you're looking for. Easily searchable, filter friendly and very much scriptable. Many TUIs including aerc and mutt can act as frontends for notmuch - though configuration may be hard. Notmuch is also supported by 'afew' - an initial mail tagger based on conditions you set (kind of like sieve, on the client side). This makes filtering of even new mails very easy. In all, I'm pretty satisfied with that side - with notmuch providing much of the flexibility and integration.
The really messy part is the server - local maildir sync part. There are half a dozen or more tools to integrate. Mbsync, OfflineIMAP and msmtp are familiar to anyone doing 2-way syncing. But if you don't want mbsync waking up every 15mins to poll the IMAP server for new mails, or if you don't want to wait 15mins for new mail, you'll have to setup a mail push notifier that that's waiting for new mail using IMAP push protocols like IDLE. That's whole another setup, just to wake up mbsync when needed. But it's still only server to localdir sync. The reverse (using file change notifiers like inotify) requires an entirely different tool with a different setup.
To make it all worse, Google has decided that they don't need to follow the standard protocols, the same way as everyone else does (for easily guessable reasons). That means that gmail needs special sync configuration or even special sync tools like lieer.
And yet another issue is that IMAP (and SMTP) are old protocols with lots of optional features bolted on. We really need a better replacement for IMAP - something like JMAP. But very few providers, servers, sync tools (any?) or clients support it.
The really messy part is the server - local maildir sync part. There are half a dozen or more tools to integrate. Mbsync, OfflineIMAP and msmtp are familiar to anyone doing 2-way syncing. But if you don't want mbsync waking up every 15mins to poll the IMAP server for new mails, or if you don't want to wait 15mins for new mail, you'll have to setup a mail push notifier that that's waiting for new mail using IMAP push protocols like IDLE. That's whole another setup, just to wake up mbsync when needed. But it's still only server to localdir sync. The reverse (using file change notifiers like inotify) requires an entirely different tool with a different setup.
To make it all worse, Google has decided that they don't need to follow the standard protocols, the same way as everyone else does (for easily guessable reasons). That means that gmail needs special sync configuration or even special sync tools like lieer.
And yet another issue is that IMAP (and SMTP) are old protocols with lots of optional features bolted on. We really need a better replacement for IMAP - something like JMAP. But very few providers, servers, sync tools (any?) or clients support it.
I frequently have to send e-mails from different addresses, so it seems I need to have manage multiple .conf files for this to work correctly? Example:
- login user: [email protected] - alises: *@example.com, [email protected], [email protected] ...
Mail addressed to "[email protected]" is delivered to "[email protected]" inbox. But instead of replying from "[email protected]", I would prefer to reply via "[email protected]"
Thunderbird offers the feature to modify the "from" header for each mail (which is nice). So I am curious how I would be able to do this with Aerc without having to constantly fiddle with the configuration files (ie, create new conf, add conf entry, ...)
- login user: [email protected] - alises: *@example.com, [email protected], [email protected] ...
Mail addressed to "[email protected]" is delivered to "[email protected]" inbox. But instead of replying from "[email protected]", I would prefer to reply via "[email protected]"
Thunderbird offers the feature to modify the "from" header for each mail (which is nice). So I am curious how I would be able to do this with Aerc without having to constantly fiddle with the configuration files (ie, create new conf, add conf entry, ...)
Aerc lets you do this, although it doesn't automatically fill it in based on the recipient in a reply. So you have to remember to adjust the sender for each email that you send.
[deleted]
That's pretty cool! I think it could use a bit more polish with the UI, maybe allow theming (for reference I did a theme for midnight commander recently - which is imo the best TUI - https://news.ycombinator.com/item?id=40741464 )
aerc is completely themable through what they call "style sets": https://man.sr.ht/~rjarry/aerc/configurations/stylesets.md
There's one big drawback I discovered the hard way, to not storing emails locally.
If you have to leave an org for any reason, you lose access to the entire email history with that org. Some of which might still be important to you for a multitude of very legitimate reasons (such as contacts).
If you have to leave an org for any reason, you lose access to the entire email history with that org. Some of which might still be important to you for a multitude of very legitimate reasons (such as contacts).
You're right about keeping an offline copy of emails - especially with the help of an indexer like notmuch or mu. But I'm not sure why you mentioned it here. In case you think that aerc supports only IMAP, it has good integration with local maildirs and notmuch. Somebody else mentioned that maildir support felt like a second class citizen. This was true during the initial phase of the project. But the developers changed their mind some time later (there's a blog post about it somewhere) and gave it a better UX.
Assuming by org you mean an employer - this is also a benefit. For legal reasons, you may not want to have a copy of any of those emails anymore, or at least your employer may not want you to.
I try to forward important e-mails to myself if I think I'll need them outside of work (insurance details, etc).
I try to forward important e-mails to myself if I think I'll need them outside of work (insurance details, etc).
> or at least your employer may not want you to
I'm not usually concerned with what the employer does or doesn't want if they've decided they don't want me.
> I try to forward important e-mails to myself
They'll invariably be aware of this.
Your employer doesn't have to know everything about your business with them. They may think they deserve to, but that doesn't necessarily mean it needs to be true for you.
One might argue that this is a bit of deception, but it's also self-preservation of self-interest.
I'm not usually concerned with what the employer does or doesn't want if they've decided they don't want me.
> I try to forward important e-mails to myself
They'll invariably be aware of this.
Your employer doesn't have to know everything about your business with them. They may think they deserve to, but that doesn't necessarily mean it needs to be true for you.
One might argue that this is a bit of deception, but it's also self-preservation of self-interest.
I love aerc but I use it with my own mail server that is on the same LAN, which makes it very fast.
For HTML, if the mail is too complicated for the text renderer, you can pipe it to your browser with a single key.
With this setup, it is quite ideal for me.
For HTML, if the mail is too complicated for the text renderer, you can pipe it to your browser with a single key.
With this setup, it is quite ideal for me.
Consider adding OAuth2.0 support. While Gmail IMAP/SMTP still supports Application Specific Passwords, you can see the writing on the wall, and the future is OAuth authentication.
It already supports it and has for years.
I miss using a TUI for mail but it looks like they haven’t really solved the most important reason I don’t, which is rendering HTML emails.
Emacs (even on the TTY), can do a decent job of rendering markup using it's built in EWW browser. Works pretty well, at least for most of the content I'm looking for.
Using it with Notmuch or mu4e is not the easiest thing to do, but it works pretty solidly.
Using it with Notmuch or mu4e is not the easiest thing to do, but it works pretty solidly.
For when eww doesn't work, this snippet will let you type "c v" in a notmuch mail buffer to render the html content of an email in an external browser:
(defun btv/notmuch-browse-html ()
(interactive "")
(let ((html-part (seq-find
(lambda (elt)
(pcase-let ((`(,begin ,end ,props) elt))
(let* ((part (plist-get props :notmuch-part))
(type
(or (plist-get part :computed-type)
(plist-get part :content-type))))
(and (equal type "text/html")
begin))))
(object-intervals (current-buffer)))))
(when html-part
(save-excursion
(goto-char (1+ (car html-part)))
(notmuch-show-view-part)))))
(add-hook 'notmuch-show-mode-hook
(lambda ()
(define-key notmuch-show-stash-map "v" 'btv/notmuch-browse-html)))I genuinely wish I liked using emacs.
Rendering HTML emails is fine, IMO, unless you want images. (I use mutt with w3m auto-view.) What’s more difficult is authoring/replying to HTML emails.
Try set send_multipart_alternative_filter=markdown2html.py [0] in your muttrc
[0] https://gitlab.com/muttmua/mutt/-/blob/master/contrib/markdo...
[0] https://gitlab.com/muttmua/mutt/-/blob/master/contrib/markdo...
You can configure aerc to pass the email contents through an intermediate program depending on the MIME type. I believe it renders HTML through w3m by default or something like that. Of course it isn't full rendering with CSS and whatnot, but it is pretty good for most mails.
Yeah, I get that, but it's still not a great experience, and inconsistent. It would be cool to see something that uses iTerm's support for inline images: https://iterm2.com/documentation-images.html
Not sure how practical that actually would be, but I can dream.
Not sure how practical that actually would be, but I can dream.
I use lynx to render html email. Other people use w3m. It's your choice and it's a solved problem.
[deleted]
I haven't tried to use this, but if someone has, how does it compare to alot (https://github.com/pazz/alot) which is the best TUI mail client I've used?
I haven't given alot much attention yet, but one feature that sets aerc apart is its focus on git-email workflow. Viewing, applying and sending patches is much easier with aerc. Remember that the author of aerc (Drew Devault) is also the developer of sourcehut.
[deleted]
nice to hear that aerc is finally getting the recognition it deserves after being in the shadows for so long. I like how simple and intuitive the account configuration is - definitely stands out compared to other clients. the folder management feature is a game-changer - goodbye messy inbox, hello organized emails!
Thanks for this. I haven't looked at aerc in a few years and this is a good reminder.
Strange. I came for the screenshots - I love a good TUI - but there were none.
The official site has video of it in use.
https://aerc-mail.org/
https://aerc-mail.org/
> This option is really simple: It allows us to override automatic sorting for certain folders. The specified folders are shown at the top of the folder list in the provided order. The rest are sorted alphabetically. This option should be in every email client. Sadly, I’ve never seen it in a graphical client (Thunderbird/Outlook) before.
Isn’t this just favorites? I’ve used them for over a decade in Outlook to keep some folders above others. It’s not configurable by a file, sure, but the feature is there.
Isn’t this just favorites? I’ve used them for over a decade in Outlook to keep some folders above others. It’s not configurable by a file, sure, but the feature is there.
In Outlook, adding a folder to "favorites" creates another reference to the folder in the favorites list; it doesn't change the all-folders view under the account.
Don't have my work laptop at hand, but I'm quite sure that you can manually order regular folders as well as favorites by simple drag and drop. In our current version at least.
It is indeed possible to reorder the regular folders as well. It's just not a favorites specific feature.
Gnome Evolution definitely supports modifying the folder sort order. There is an "Edit sort order" option in the "Folder" menu.
[deleted]
pine
> Email authoring is an absolute pleasure. I really like the fact I can now compose my emails in vim.
Say no more.
Say no more.
[deleted]
I might be missing something but why would you want to use a terminal interface when a GUI is so much easier?
Personal preference. Perks include consistency and hackability. Mutt for instance hasn't changed a whole lot in decades. The relative simplicity and stability also means I'm not running into a whole lot of bugs. GUI email clients on the other hand...
Resource usage is also about as low as you can get.
Resource usage is also about as low as you can get.
Your are indeed! Many people like myself prefer the lightning fast interaction of keyboard navigation, the mastery of the bindings to improve workflows, and the customization of bindings to create new ones.
Aren’t keyboard shortcuts and TUI/GUI pretty orthogonal? Is there not GUI client that has proper keyboard navigation?
ok but GMail for example has keyboard shortcuts.
GMail, the web client, is an almost worthless email client. It has like maybe 1% of the features of thunderbird.
As with most web apps, it's more of a preview than an application.
As with most web apps, it's more of a preview than an application.
Yeah, but I don’t have to learn new shortcuts since I can configure Aerc exactly like I want (and how my mental VIM shortcut model works).
This has to be a pretty backwards argument, to be honest.
You may not have to learn "new shortcuts" (they're pretty standard), but you're perfectly willing to learn an entire text-based configuration scheme?
VIM has its merits for _editing_ code, but that's not what you're doing with e-mails. You're usually just writing them and sending them off. It doesn't matter if you can save a few keystrokes to, say, change a word a few paragraphs back, and you're not producing structured text in any meaningful way.
It's perfectly fine to like the terminal, but you _have_ to admit it is a preference that has nothing to do with "efficiency".
You may not have to learn "new shortcuts" (they're pretty standard), but you're perfectly willing to learn an entire text-based configuration scheme?
VIM has its merits for _editing_ code, but that's not what you're doing with e-mails. You're usually just writing them and sending them off. It doesn't matter if you can save a few keystrokes to, say, change a word a few paragraphs back, and you're not producing structured text in any meaningful way.
It's perfectly fine to like the terminal, but you _have_ to admit it is a preference that has nothing to do with "efficiency".
I must respectfully disagree. It's far from just about writing an email; it's about managing hundreds of emails. With Vim keybindings, I can switch between email accounts, folders, and individual emails in Aerc at lightning speed. I can select emails using the same keybindings as I would to select lines of text in Vim. Then, I can use those same keybindings to delete, move, copy, or mark emails. The efficiency? It's many times better once you understand the Vim mindset. Plus, I can use the same keybinding system in other programs too. Take a look at [oil.nvim](https://github.com/stevearc/oil.nvim), NNN, or [yazi](https://github.com/sxyazi/yazi), or mpv or surfingkeys in your browser.
For Yazi, I even created a hardcore Vim configuration that makes it even easier and more efficient for any user familiar with Vim keybindings.
Just one example: look at your email program. Perhaps you have a folder open with 100 emails. Now, imagine that each email is nothing more than a line of text. So, you have a document with 100 lines of text. In Aerc, I can simply jump to the first line (the first email) with `gg`. And with `G`, I can jump to the last email. With `ff`, I filter all emails that have the same sender. With `fs`, all that have the same subject. With `V`, I mark an email, and with `X` or `dd`, I can delete the email. Before that, I can mark all the emails I filtered with `G`. If I don't want to delete them but move them instead, I just press `pf` and enter the first letters of the desired folder where I want to move my emails. I can also set certain folders where I often move emails as shortcuts. For example, `pb` to move emails to the "Brain" folder. Have a look at my simple config: https://github.com/rafo/aerc-vim/blob/main/binds.conf
Once understood, everything becomes incredibly fast.
Tip: try surfingkeys in your browser.
For Yazi, I even created a hardcore Vim configuration that makes it even easier and more efficient for any user familiar with Vim keybindings.
Just one example: look at your email program. Perhaps you have a folder open with 100 emails. Now, imagine that each email is nothing more than a line of text. So, you have a document with 100 lines of text. In Aerc, I can simply jump to the first line (the first email) with `gg`. And with `G`, I can jump to the last email. With `ff`, I filter all emails that have the same sender. With `fs`, all that have the same subject. With `V`, I mark an email, and with `X` or `dd`, I can delete the email. Before that, I can mark all the emails I filtered with `G`. If I don't want to delete them but move them instead, I just press `pf` and enter the first letters of the desired folder where I want to move my emails. I can also set certain folders where I often move emails as shortcuts. For example, `pb` to move emails to the "Brain" folder. Have a look at my simple config: https://github.com/rafo/aerc-vim/blob/main/binds.conf
Once understood, everything becomes incredibly fast.
Tip: try surfingkeys in your browser.
There is a different social contract between GUI and CLI project maintainers and their users. A menu item can be renamed or moved around and the only thing that breaks is the mental model of users who knew precisely where that menu item was; a CLI option, for example, cannot be renamed or removed without breaking someone's automated script.
Given that difference, some people prefer the stability of their tools not changing on them and prefer CLI/terminal work in general. The difference in social contract may not apply specifically to an email client but a given user might be more comfortable in a terminal than in a GUI.
Given that difference, some people prefer the stability of their tools not changing on them and prefer CLI/terminal work in general. The difference in social contract may not apply specifically to an email client but a given user might be more comfortable in a terminal than in a GUI.
Really short answer: Because the GUIs for mail SW are just not that great. It's been a long time since I used something like Thunderbird, but for the webmails I use, as well as Outlook at work - both tend to have inferior UIs than a good TUI.[1]
Another short answer: A lot of people prefer to use the keyboard. While it's true you can do a lot of keyboard navigation in some GUIs, but they still tend to be inferior to what you can do in a GUI.
Another answer: Performance. GUIs in general are laggy.
Another answer: What are my choices for GUIs for local mail? I always store mail locally on my PC and use a mail SW to interact with them.
Fundamentally, GUI developers optimize for different things compared to TUI developers.
Finally:
> but why would you want to use a terminal interface when a GUI is so much easier?
I think you'll find that the HN crowd values a few things higher than "ease". Yes, GUIs tend to be easier. Just like using IFTT is easier than writing code. Yet, many people prefer to write code.
[1] I mean OK, perhaps for a thing or two they're better, but not overall.
Another short answer: A lot of people prefer to use the keyboard. While it's true you can do a lot of keyboard navigation in some GUIs, but they still tend to be inferior to what you can do in a GUI.
Another answer: Performance. GUIs in general are laggy.
Another answer: What are my choices for GUIs for local mail? I always store mail locally on my PC and use a mail SW to interact with them.
Fundamentally, GUI developers optimize for different things compared to TUI developers.
Finally:
> but why would you want to use a terminal interface when a GUI is so much easier?
I think you'll find that the HN crowd values a few things higher than "ease". Yes, GUIs tend to be easier. Just like using IFTT is easier than writing code. Yet, many people prefer to write code.
[1] I mean OK, perhaps for a thing or two they're better, but not overall.
Personally I use a hybrid, or Emacs under X11, witch is arguably a GUI but also text-based and why for me is because of:
- integration :: I can create in a single keypress (bind to org-store-link) a link to be inserted in a note (another single keypress, org-insert-link) to pretty anything, a specific place in a file, a whole file to be open with a specific app, a mail message, ...
- end-user-programming :: meaning I can easily have a function (or a script, outside Emacs, maybe) that when a new electricity bill email arrive to my inbox it add relevant information in the relevant contract note, an agenda info, a "special timer" [1] that check my BeanCount transaction for a relevant entry after a certain date etc. With LITTLE coding an user can get a personal BI without a BI monster and issues of feeding it all the time.
GUIs suffer from not being textual enough, TUIs due to the lack of full graphics abilities.
Desktop computing in a network is the most powerful form of computing we have, and unfortunately it's long lost for a modern mainframe model (cloud+mobile) witch is terribly limited and limiting and most not knowing anything else do not even understand the limit.
[1] a function that run at a date, and get re-created when a session restart to avoid loosing the timer after a reboot
- integration :: I can create in a single keypress (bind to org-store-link) a link to be inserted in a note (another single keypress, org-insert-link) to pretty anything, a specific place in a file, a whole file to be open with a specific app, a mail message, ...
- end-user-programming :: meaning I can easily have a function (or a script, outside Emacs, maybe) that when a new electricity bill email arrive to my inbox it add relevant information in the relevant contract note, an agenda info, a "special timer" [1] that check my BeanCount transaction for a relevant entry after a certain date etc. With LITTLE coding an user can get a personal BI without a BI monster and issues of feeding it all the time.
GUIs suffer from not being textual enough, TUIs due to the lack of full graphics abilities.
Desktop computing in a network is the most powerful form of computing we have, and unfortunately it's long lost for a modern mainframe model (cloud+mobile) witch is terribly limited and limiting and most not knowing anything else do not even understand the limit.
[1] a function that run at a date, and get re-created when a session restart to avoid loosing the timer after a reboot
A constrained environment forces developers to distill to the essence of the problem, thereby possibly understanding it better. It's the old "simple can be harder than complex" attributed to Steve Jobs.
Operation via single-character keyboard commands is really fast in TUI emails clients. In principle a GUI client could offer the same, but I haven’t seen one that does to the same degree. A GUI might be “easier”, but is less efficient for the power user.
Another reason that is more idiosyncratic: If you operate your own email server, you can SSH in from everywhere and use a TUI client locally on the server. This saves the transferring/syncing of emails between client-side local storage and the server; everything is just immediately available.
Another reason that is more idiosyncratic: If you operate your own email server, you can SSH in from everywhere and use a TUI client locally on the server. This saves the transferring/syncing of emails between client-side local storage and the server; everything is just immediately available.
Gmail is actually really good with this. Yeah, not every possible action has a keyboard shortcut, but all the important ones do (the ones you will realistically use in day to day email handling).
Why would you want to use a cartoonish GUI for a text application like email when using a terminal interface is so much easier?
Convenience is valuable, but the sense of coolness is equally important. Perhaps it's all about the feeling.
I find neomutt much easier* than a GUI, especially since I can write my emails using vim. But also, since I get a lot of notifications via email, I can do things like bulk-delete by just typing D + [pattern]
*Once configured, which is definitely not easy.
*Once configured, which is definitely not easy.
I'm guessing that the text interface is nicer if your use case is reading mostly text-based emails from newsletters or forums. But yeah, for general email use I don't see this as a plus unless you really like TUIs.
[deleted]
Besides the other reasons already posted, one big one if one runs one's own email server (have done so since circa 1999) is that remote access to email is just an ssh session.
You will find no logical answer, it's a religious issue at this point.
focus, performance on old/low power hardware.
[deleted]
hdhgwdg(1)
Looks good but wish it was written in C.
The original aerc prototype was written in C. It wasn't great.
https://git.sr.ht/~sircmpwn/aerc-legacy
https://git.sr.ht/~sircmpwn/aerc-legacy
For anyone else wondering, it is written in Go.
Go it's ideal to replace old C/C++ based utilitarian software such as mail clients, music players and so on.
For gaming and high performance needing tools such as the ffmpeg codecs and qemu, C/C++ have more sense there.
[deleted]
> In most multipart emails the plain text version is much less readable than the HTML version. It’s possible to grasp the meaning most of the time but sometimes it is just a garbled mess. Aerc has a few features to make this experience less bad. One option is viewing them through a HTML parser/browser (a combination of w3m and dante. This works well for some emails. The generated output is sometimes better than the plain text version of the email
This seems like a perfect use case for a (local) LLM. Feed in the HTML and extract a clean plaintext version.
This seems like a perfect use case for a (local) LLM. Feed in the HTML and extract a clean plaintext version.
This is the first I've read of "TUI" standing for what I have to assume is "terminal user interface"? I'd call them CLI (command line interface). When did this TUI acronym start? What does it mean? Everyone else seems to know it and use it without defining.
I dont know when it exactly started but I've heard and use this term at least 15 years. CLI != TUI. TUI is more like a "standard" window (GUI) but all text based.
Well... CLI is Command Line Interface, or a classic ./name --options reading output in a terminal and writing options, piping to other tools to tweak the output. It's good for some usages, and for scripting, but not much for event-loop based activities.
TUI, Textual User Interface today tend to be a 2D terminal graphic, from ncurses to framebuffer. Classically it's simply a 2D UI based on text, so for instance Plan 9 ACME editor is a TUI since it's graphic but you can write text anywhere creating and changing menus, toolbars etc.
I think there is no official Jargon File entry to clarify this, 99% of the time people name TUI an ncurses UI, witch is a debatable since it can be not really usable as text and so as Terminal User Interface, but a CLI is also a terminal user interface.
TUI, Textual User Interface today tend to be a 2D terminal graphic, from ncurses to framebuffer. Classically it's simply a 2D UI based on text, so for instance Plan 9 ACME editor is a TUI since it's graphic but you can write text anywhere creating and changing menus, toolbars etc.
I think there is no official Jargon File entry to clarify this, 99% of the time people name TUI an ncurses UI, witch is a debatable since it can be not really usable as text and so as Terminal User Interface, but a CLI is also a terminal user interface.
CLIs can be graphical too! One classic example is AutoCAD:
> The command line interface provides an important method for controlling AutoCAD. For many users, it is the primary input method. The command line is also used for displaying and selecting command options.
https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-F145...
> The command line interface provides an important method for controlling AutoCAD. For many users, it is the primary input method. The command line is also used for displaying and selecting command options.
https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-F145...
Very right indeed, maybe then:
- GUI :: graphical UI, typically NOT easy to mold by the end users, mostly widget based UIs, as their main characteristic or the user of them is more a consumer than a producer of something;
- CLI :: a REPL, typically a terminal, but definitively not only that, their users enter commands, read responses as main characteristic;
- TUI :: a 2D UI (typically though it could probably be also a 3D and 4D one) easy to be mold by the end user, the user is both a producer and a consumer as their main characteristic. An WYSIWYG editor is a kind of TUI in that regard, an Emacs buffer is another since in both text can be entered somewhat freely and can became "active" like clickable links. The user read, or consume, but also write, or produce.
An ncurses UI should be TUI being text-based and 2D but still lack the user mold part so well... Still unsure how to classify the acronym...
- GUI :: graphical UI, typically NOT easy to mold by the end users, mostly widget based UIs, as their main characteristic or the user of them is more a consumer than a producer of something;
- CLI :: a REPL, typically a terminal, but definitively not only that, their users enter commands, read responses as main characteristic;
- TUI :: a 2D UI (typically though it could probably be also a 3D and 4D one) easy to be mold by the end user, the user is both a producer and a consumer as their main characteristic. An WYSIWYG editor is a kind of TUI in that regard, an Emacs buffer is another since in both text can be entered somewhat freely and can became "active" like clickable links. The user read, or consume, but also write, or produce.
An ncurses UI should be TUI being text-based and 2D but still lack the user mold part so well... Still unsure how to classify the acronym...
I've also never heard this term. Back when text interfaces for mail were the default, but they started getting "fancy" like elm, pine and mutt in the 90s, they were always called curses or ncurses interfaces. When GUIs became a thing, the older things became called text-mode, but I've never encountered TUI before.
The only TUI that I'd heard of is the travel company.
The only TUI that I'd heard of is the travel company.
curses and ncurses are specific libraries used while TUI is a more universal term.
But what does it actually stand for? Terminal user interface? Text user interface? I'm not complaining or saying it shouldn't be used, I'd just never seen it before and my initial searches for TUI were all overloaded with other things.
> But what does it actually stand for? Terminal user interface? Text user interface?
Yes.
https://en.wikipedia.org/wiki/Text-based_user_interface
The Wikipedia page is from 2004, so it's been around a while.
Yes.
https://en.wikipedia.org/wiki/Text-based_user_interface
The Wikipedia page is from 2004, so it's been around a while.
I've seen TUI used for at least a decade? Things like this used to be just called "GUIs" even when running fully in text-mode back in the DOS days.
IMO "ed" is a CLI (i.e. the primary form of interaction is a command line), and "vi" is a TUI.
IMO "ed" is a CLI (i.e. the primary form of interaction is a command line), and "vi" is a TUI.
It's been in use since at least the late 1980s to early 1990s. I believe it was in the Turbo Pascal for DOS documentation I used back then, as well as Turbo Vision and some other things. I also worked on a TUI library for Euphoria in DOS around that time.
And it means a full-screen Text User Interface, which is quite different from a line-oriented CLI (Command Line Interface). Instead of a command line, you have a full screen interface with menus, dialogs, buttons, checkboxes and radios, listboxes, windows, scrollbars, etc. Just all in text mode using things like the box drawing and shading characters.
So at least 30 years ago. Probably the early 80s, although I'm not sure of that. But that's when some programs started going from CLI or forms-based to actually using that full-screen TUI style.
The earlier forms-based programs were basically just a hard-coded text-mode screen with blank fields that you could fill in the blanks, then hit a key to either submit, escape back out, or use a hotkey to pull up a different form screen. They didn't have the various interface widgets that we got used to with the TUIs and later GUIs.
And it means a full-screen Text User Interface, which is quite different from a line-oriented CLI (Command Line Interface). Instead of a command line, you have a full screen interface with menus, dialogs, buttons, checkboxes and radios, listboxes, windows, scrollbars, etc. Just all in text mode using things like the box drawing and shading characters.
So at least 30 years ago. Probably the early 80s, although I'm not sure of that. But that's when some programs started going from CLI or forms-based to actually using that full-screen TUI style.
The earlier forms-based programs were basically just a hard-coded text-mode screen with blank fields that you could fill in the blanks, then hit a key to either submit, escape back out, or use a hotkey to pull up a different form screen. They didn't have the various interface widgets that we got used to with the TUIs and later GUIs.
You've charted an incredibly fortuitous TUI-avoiding path through your HN reading, it pops up constantly. Just in the last year:
https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
vim and midnight commander are TUI
bash and git are CLI
bash and git are CLI
- I have redefined the Aerc key mapping with a set of Vim-like keybindings, since I am too old to learn new keybindings. And I bet now I as fast as possible slashing through countless mails…
- I configured Aerc to work properly with Gmail and Imapfilter.
- I created some filters that I missed from any mail client I ever tried (at least two keystrokes away). Like:
If someone is interested, I will link my GitHub repo.