A little while ago I wrote my own little TUI tool using Textual that interfaces with Outlook using pywin32. I really only needed (need) one specific feature above and beyond what Outlook already does. And that is, I wanted a Vim-like UX for assigning categories to emails and archiving/deleting them. What I have now works surprisingly well and it's very satisfying to have made my own thing that suits my own needs precisely the way I want it to.
For one thing, while I know Python a little bit, I much prefer to write Lisp. But the Textual [0] library is for Python and nothing else seems to even compete in the same space. So my "outlook-explorer" ("oe" on my command line) is actually written in Hy [1], a Lisp-y syntax swap that emits Python AST objects. And there's a couple places where I just hard-coded my own info, like the email address I'm using it with in order to pull from the right inbox in Outlook, that would need some kind of user-facing and reasonably user-friendly config options before it'd be ready for general consumption.
Have you thought about making your own bespoke one-of-one thing? I got much further than I expected to in only a couple hours. It was already basically functional in three hours, I think, and I came to the table with no prior experience using Textual.
Most of the email tools like notmuch tend to be GPL which limits adoption IMHO.
From strictly reading the docs, I love these features:
* oauth2 * json output
But do I need to run the "himalaya ..." command every so often to get fresh e-mails? Or can I leave TUI open and it will refresh in the background?
When composing messages, does anybody know if the "From" header can be re-written like in Thunderbird? I am able to send from ad-hoc aliases with my mail server, but need to re-write the "From" header first. For example, I can receive mail sent to "xyst.hn@example.com" and delivered to mailbox at "xyst@example.com". In order to reply with same e-mail address, I must re-write the "From" header to match.
Being able to select emails using regular expressions is super useful.
IMAPFilter is also simple and powerful to quickly sort email.
I am also able to integrate (a locally hosted) LanguageTool to check the grammar in the editor.
The only issue is to write emails with embedded images. But personally I don't like such emails for occupying the space of the mailbox.
Here is and example of a config file for a gmail address :
```
host: imap.gmail.com
port: 993
tls: true
tlsOptions:
rejectUnauthorized: false
username: {{ youremailaddresshere }}
password: ''
passwordCMD: pass mw/{{ youremailaddresshere }} | head -n1
onNewMail: mailsync {{ youremailaddresshere }} | while read OUTPUT; do notify-send "" "$OUTPUT"; done
onNewMailPost: ''
onDeletedMail: ''
onDeletedMailPost: ''
boxes:
- INBOXEdit: there is a separate tool for this for gmail https://github.com/mbrt/gmailctl
Same and also `nmh`. Loved how you could combine the various parts to make your own tools.
#!/bin/bash
while true; do
# Run the command and capture its exit code
result=$(himalaya envelope list --folder INBOX --page 1 --page-size 100 --output json not flag Seen | \
jq -r '.[] | "\(.id) Seen"')
exit_code=$?
# Check the exit code of `himalaya`
if [[ $exit_code -ne 0 ]]; then
echo "No more unseen emails to process or an error occurred."
break
fi
# Check if result is empty
if [[ -z "$result" ]]; then
echo "No more unseen emails to process."
break
fi
# Process unseen emails
echo "$result" | xargs himalaya flag add
echo "Processed unseen emails. Checking for more..."
done
Another idea I had was to use it to sort mails into folders by the receipient address suffix (my.name+amazon@example.com would sort into the amazon folder), which should be possible if I have read the man pages correctly.
Anyway, thanks for this, not sure if this is the "best" way for me to work with mails but it absolutely is the first tool that made me start automating my inbox.
I do see
$ himalaya envelope list --account posteo --folder Archives.FOSS --page 2
I guess my question is: is this different than PINE (or any other terminal-based, interactive email client)?
https://github.com/leahneukirchen/mblaze/tags
And correspondingly of course that’s the version package repos have/will published too.
For example, Alpine Linux has that version in a community package repo on a branch.
https://pkgs.alpinelinux.org/package/edge/community/x86/mbla...
FreeBSD package repo is a little behind, still on v1.2 instead of v1.3. But that’s still a version from March of this year.
https://www.freshports.org/mail/mblaze
And even if the most recent release of mblaze really had been a few years ago, it could still be good software. Especially for email.
feature not a bug
> does not work on Windows
ditto
I'd love to see a blog or some post on the roadmap for this project (and the org in general).
Edit: That is indeed exactly what this is. It's wonderful :)
The “MML” MIME markup language is new to me. It is strange that it’s neither markdown based nor does it automatically build the plain text part for you.
On the few occasions these days where I compose an email in mutt (via vim) I find I end up writing markdown _anyway_* so supporting it as an authoring format would be fantastic.
Alas, a lot of professional interactions require HTML emails. I don’t want to come across as awkward nerd to everyone all the time.
*!:)
Thunderbird can sync with Microsoft 365 for Enterprise mail servers and can be configured to store email in a maildir format. So you could use Himalaya to read emails that Thunderbird synced, but you can't manipulate Thunderbirds maildir.
I don't mean this in the way that Client A > Client B, but I have spent a fair amount of thought on this, and I have not been aple to pinpoint exactly what characteristics makes the difference for me, which I find to be interesting in itself.
I noticed that letting mails linger in sight in my inbox is energy draining or causes me to procrastinate.
This is unacceptable to me. Yet I keep using it because I dislike Gmail’s web interface and my Vim imap setup is not really usable yet and probably never will be.
I've used many, many different clients over the last few decades (yes, including Linux `mail`). I have to use Outlook at work, and I have to use my providers' web clients on my Windows gaming PC, but on all my other devices I use Mail.app.
I just... don't ever use all the features of the other clients, or don't like some of the behavior they have, or any of that. For a long time I would get excited about new email clients and try them out right away, but no more.
I dunno if it's just that I'm getting old, or if I just don't care as much, or both, or something else.
I have found a sweet spot for an email client between a pure CLI and a full-featured (HTML) GUI client - I use Emacs Gnus, which takes full advantage of Emacs' text-based interface. As always with Emacs, the learning curve is a bit steep at first, but the rewards can be reaped afterwards.
For any Emacs users who are interested in using Emacs for mail but don't want to deal with the learning curve of Gnus, check out mu4e, which is easier.
I was one of these die-hard-text-only people, back in the mid to late 90s. It was true. People were sending HTML/rich text emails, and it broke everything, and it was awful to read with. Not to mention the kilobytes of bandwidth wasted!
But it's 2024 now. There are vastly more tools that can deal with HTML email than those that can't. Like, I wouldn't be surprised if it's 4 orders of magnitude.
Sorry, folks, we lost. Email is not plain text any more. We can't pretend that it is or should be.
To answer your question, these days, I’m not sure. There are so many extra features that email providers (Gmail/Office365) include in their web interfaces, it’s hard to not make the argument that the web interfaces are the better way to use email.
It's also often convenient to either script interactions, or to have full access to shell tools when interacting with email. I practice this more often with mutt, but I can filter either messages or metadata (headers) and send those to an awk or sed pipeline to extract specific information of interest (this is especially useful with notifications / alert emails). This might be tens, hundreds, thousands, or more messages that are of interest.
Full-blown GUI or Web client email tools are pretty, but lack this flexibility.
First is the use of mailboxes if your mail provider does not provide you with an IMAP server to connect to in which case you'll use a client like mutt to manage your mails.
Second one is the accesibility through the terminal could be reduced with HTML sites. If I want to access my email through a headless server using lynx or similar having to refresh the website to check new mails, or even composing them might be difficult.