Himalaya makes it pretty easy to write cli tools and automate email workflows. It pairs well with August, another rust project that can render html to text on the terminal. I wrote a git email patch automation tool around Himalaya so that people can receive email patches easily[1].
This is cool. I like the ongoing trend of TUIs getting more attention and use.
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.
I feel like this has been here before, glad it's kept up with updates. Will have to give this a shot soon.
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.
It's designed to be a CLI tool as opposed to a TUI so that it's more composable with other CLI tools. So you can use it as a building block to create a TUI, but it's not one by default.
Yes! I use mutt for searching, tagging, thread operations (splitting,appending etc.), bouncing, attaching other mails, deleting attachments, openpgp (personal), smime (at work), and it works with IMAP out of the box.
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.
Does it support email filters? I'd love to manage my gmail filters programmatically or use a configuration file to manage them so I can reuse the filters across multiple emails.
Neat. I used and loved “mh” in college, but that was before html email became prevalent. It was beautiful to have different commands and treat emails as individual files. Unfortunately mh was grotty old C code and just couldn’t keep up (IMHO) with how we use email today.
I think the README is missing some examples of what this can do. I used it for a script that marks every mail as seen:
#!/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
I'm not a shell coder and while writing the script I wasn't sure if the better way would have been to use the underlying Rust library, but that probably would have taken longer to build for such a small task.
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.
Been eyeing this project for a while, hesitant to pull the trigger before a 1.0, just because email is a pain to configure, and having to keep up with changes before a 1.0 would have been a pain.
I'd love to see a blog or some post on the roadmap for this project (and the org in general).
This looks like it's a "real" CLI instead of a curses thing (TUI?). That's really exciting for me. I strongly prefer tools that can be composed as a standard shell pipeline.
Edit: That is indeed exactly what this is. It's wonderful :)
Amazing! Love the idea, and I really love the “sponsorship” part. It’s very cool that a project like this can get funding.
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.
Depends, likely not as Microsoft strongly recommends disabling IMAPv4 and POP3 access to mailboxes in 365 and I think it's now the default. Most company policies do not allow it to be enabled outside service mailboxes.
Do you mean Microsoft 365 for Enterprise? Teams is the chat app.
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.
Mail causes me to procrastinate so much, and I have no idea why. I use icloud everything, so I wanted my mail there as well, but after 12-13 months I switched back to FastMail because their UX is subtly better suited to quickly sorting through mail for me. And fwiw I'm afaik not using any FastMail features that Mail doesn't have.
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.
Last week I searched for an email in Mail.app. It was right there on the screen and it couldn’t find it. It also fails to display or even list some attachments.
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.
Indeed, I'm additionally using https://mimestream.com for company Gmail as the Gmail support in Mail.app is sometimes a bit lacking (Labels etc.), but it's also a good way to keep private and work emails separated.
I feel you. I now just use email in my web browser via the respective providers recommended website, aka mail.google.com, microsoft.office365.exchange.email or whatever it is they are calling it these days.
I just wish that Mail.app would have a seamless ingegration with Calendar.app like Microsoft already provides with Outlook. Also the label system feels very outdated compared to Outlook.
They are, but I have a cron job that fetches my email every 5 minutes. No need to keep a tab open, or do the auth routine again and again. And I used to put an indicator in my status bar displaying the unread count. There’s a whole world of integration when you just dig a bit deeper.
There are many choices for email client interfaces. HTML for email does not have a good reputation among hackers. After all, email can be considered an ancient technology and is historically based on plain text - HTML breaks not only the philosophy but also many of the tools developed around email.
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.
This question shows how far we’ve travelled from the original concepts of sending/receiving/viewing email. I just found it funny that you said “regular HTML client”, as if that was the default interface for email. Originally, it was all text, so this post is in many ways closer to how many thought of a “regular” client. But ever since Hotmail, it’s been a gradual shift away from command line email towards web applications. Desktop GUIs are still (kind of) holding on, but even they are more likely than not to be an Electron app.
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.
There are times it's really useful to access email from a terminal, and terminals are widely available (shell on your primary system, Termux on Android, SSH to your email host, whatevs).
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.
I don't have much knowledge regarding mail but I can think of two reasons.
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.
djha-skin|1 year ago
1: https://github.com/djha-skin/git-receive-mail
cfiggers|1 year ago
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.
rubicks|1 year ago
xyst|1 year ago
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.
faitswulff|1 year ago
jedisct1|1 year ago
Being able to select emails using regular expressions is super useful.
IMAPFilter is also simple and powerful to quickly sort email.
drwu|1 year ago
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.
msravi|1 year ago
aynawn|1 year ago
Edit: there is a separate tool for this for gmail https://github.com/mbrt/gmailctl
jonstewart|1 year ago
https://en.m.wikipedia.org/wiki/MH_Message_Handling_System
bandie91|1 year ago
[1] https://codeberg.org/hband/gemlv#emlv
zimpenfish|1 year ago
Same and also `nmh`. Loved how you could combine the various parts to make your own tools.
alberth|1 year ago
jarbus|1 year ago
vigonotion|1 year ago
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.
brink|1 year ago
oblio|1 year ago
MikeTheGreat|1 year ago
I do see
and a screenshot that looks like PINE. Is that screenshot interactive (like PINE) or does himalaya print that out and then the process exits?I guess my question is: is this different than PINE (or any other terminal-based, interactive email client)?
fabrixxm|1 year ago
zokier|1 year ago
tempfile|1 year ago
https://github.com/leahneukirchen/mblaze
38|1 year ago
JeremyHerrman|1 year ago
jarbus|1 year ago
I'd love to see a blog or some post on the roadmap for this project (and the org in general).
throwthrow4567|1 year ago
delusional|1 year ago
Edit: That is indeed exactly what this is. It's wonderful :)
gorgoiler|1 year ago
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.
*!:)
pydry|1 year ago
taylorbuley|1 year ago
kedarkhand|1 year ago
jxf|1 year ago
stackskipton|1 year ago
teruakohatu|1 year ago
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.
michaelmior|1 year ago
nixosbestos|1 year ago
stabbles|1 year ago
hk1337|1 year ago
varunneal|1 year ago
szajbus|1 year ago
kriops|1 year ago
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.
tambourine_man|1 year ago
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.
bovermyer|1 year ago
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.
dewey|1 year ago
markatkinson|1 year ago
marcomourao|1 year ago
https://freron.com/
siva7|1 year ago
krembo|1 year ago
alchemist1e9|1 year ago
szundi|1 year ago
arminsergiony|1 year ago
[deleted]
unknown|1 year ago
[deleted]
oldpersonintx|1 year ago
skydhash|1 year ago
rs812005|1 year ago
[deleted]
ferdws221133|1 year ago
[deleted]
zerop|1 year ago
smartmic|1 year ago
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.
mbreese|1 year ago
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.
dredmorbius|1 year ago
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.
tacomagick|1 year ago
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.