One of the major reasons I use Gmail in the browser is because it’s in the browser: it’s always on the same tab and I can switch to it when I want to check it. I used Mutt (unsuccessfully) a few years ago since my other window that’s always open is a terminal emulator.
I wonder: should I fire up a Linux emulation in my browser and run Mutt inside that? I’m sure things have gotten fast enough that this would actually work.
I don't know about Gmail in the browser because I access it via IMAP and SMTP, but I have noticed that the browser process that's associated with tab that has the Google voice page open will occasionally start consuming a lot of CPU and memory resources to the point that I have to terminate the process.
This never happens with Thunderbird and is even less likely to happen with a TUI client like Mutt.
If you are already productive with Gmail and its web UI, why change?
I love mutt and have used it in the past, but I'm very productive with Gmail in the browser, especially with the vim-like shortcuts it provides and with an inbox-zero-like workflow.
I use mutt for Gmail in my terminal, the setup is fairly easy and documented across blog posts
example muttrc
=========================================================
set imap_user = '<username>@gmail.com'
set imap_authenticators="oauthbearer"
set imap_oauth_refresh_command="~/.mutt/oauth2.py --quiet --user=<username>@gmail.com --client_id=<id from google>.apps.googleusercontent.com --client_secret=<secret from google> --refresh_token=<token from, you guessed it, google>"
set smtp_authenticators="oauthbearer"
set smtp_oauth_refresh_command="~/.mutt/oauth2.py --quiet --user=<username>@gmail.com --client_id=<id from google>.apps.googleusercontent.com --client_secret=<secret from google> --refresh_token=<token from google>"
set ssl_starttls=yes
set ssl_force_tls=yes
set imap_pass = 'my really hard to guess gmail password'
set from='<username>@gmail.com'
set realname='Fancy pants name'
set folder = imaps://imap.gmail.com/
set spoolfile = +INBOX
set record = "+[Gmail]/Sent Mail"
set postponed = "+[Gmail]/Drafts"
set trash = "+[Gmail]/Trash"
set postponed="imaps://imap.gmail.com/[Gmail]/Drafts"
set header_cache = "~/.mutt/cache/headers"
set message_cachedir = "~/.mutt/cache/bodies"
set certificate_file = "~/.mutt/certificates"
set smtp_url = 'smtp://<username>@gmail.com:<my really hard to guess password>@smtp.gmail.com:587/'
set smtp_pass = 'my really hard to guess password'
set move = no
set imap_keepalive = 900
#refresh every 10 seconds
set timeout=10
set mail_check=20
# allow mutt to open new imap connection automatically
unset imap_passive
# vim!
set editor=vim
# email sorting
set sort=threads
set sort_browser=reverse-date
set sort_aux=last-date-received
# handy macros
macro index gd "<change-folder>$postponed<enter>" "go to drafts"
macro index gs "<change-folder>$record<enter>" "go to sent"
macro index gi "<change-folder>$spoolfile<Enter>" "go to inbox"
macro index gt "<change-folder>$trash<enter>" "go to trash"""
Sure, but the problem of storing messages indefinitely isn't from the protocol, it's from the client. The client may need to verify if it's actually seen a message before and keep a local index of them; it may need to double check the message still is what it expects before it tries to delete it; it needs to present you with options on how to handle message deletion; etc.
POP3 is actually less reliable at keeping messages indefinitely than IMAPv4 is, due to limitations of the protocol. Some clients have defaults which simply delete the remote copy after download (or reading, which is different), but again that's not the protocol's fault.
I wonder: should I fire up a Linux emulation in my browser and run Mutt inside that? I’m sure things have gotten fast enough that this would actually work.