- 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:

  ff = :filter -f "{{index (.From | emails) 0}}"  # filter mails from current sender
  fs = :filter -H subject:"{{.SubjectBase}}"  # Show Mails with the same subject
  fS = :filter -H subject: # filter mails with subject e.g. "fs foo" filters mails with subject containing "foo"
 

'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.

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!

- 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/

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 # move (think put or paste) mail in the archive folder
  pb = :move Brain # move mail in my Brain.
  pf = :move # 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 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.

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 don't use it for work, only personal use, though, so ymmv.

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.

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.

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.

1: https://github.com/wangp/bower

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

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.

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.

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 wonder if one could develop a decent TUI for Thunderbird / its database...

One of these days I will convert my mbox mail to Maildir and try out notmuch.

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.

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.

For me outlook is the real pain, I just redirect my emails there to my gmail.

- 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, ...)

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 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...

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!

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...

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.

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.

Using it with Notmuch or mu4e is not the easiest thing to do, but it works pretty solidly.

    (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)))

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.

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.

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).

I try to forward important e-mails to myself if I think I'll need them outside of work (insurance details, etc).

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.

Resource usage is also about as low as you can get.

As with most web apps, it's more of a preview than an application.

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".

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.

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.

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 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.

*Once configured, which is definitely not easy.

- 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

The only TUI that I'd heard of is the travel company.

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.

- 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...

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.

IMO "ed" is a CLI (i.e. the primary form of interaction is a command line), and "vi" is a TUI.

This seems like a perfect use case for a (local) LLM. Feed in the HTML and extract a clean plaintext version.