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].<p>1: <a href="https://github.com/djha-skin/git-receive-mail">https://github.com/djha-skin/git-receive-mail</a>
This is cool. I like the ongoing trend of TUIs getting more attention and use.<p>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.<p>From strictly reading the docs, I love these features:<p>* oauth2
* json output<p>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?<p>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.
I still use mutt on a daily basis.<p>Being able to select emails using regular expressions is super useful.<p>IMAPFilter is also simple and powerful to quickly sort email.
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.<p>Edit: there is a separate tool for this for gmail <a href="https://github.com/mbrt/gmailctl">https://github.com/mbrt/gmailctl</a>
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.<p><a href="https://en.m.wikipedia.org/wiki/MH_Message_Handling_System" rel="nofollow">https://en.m.wikipedia.org/wiki/MH_Message_Handling_System</a>
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:<p><pre><code> #!/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
</code></pre>
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.<p>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.<p>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.
Genuine question - the HN title says "CLI to..." but looking at the GitHub repo I don't see any CLI-centric documentation.<p>I do see<p><pre><code> $ himalaya envelope list --account posteo --folder Archives.FOSS --page 2
</code></pre>
and a screenshot that looks like PINE. Is that screenshot interactive (like PINE) or does himalaya print that out and then the process exits?<p>I guess my question is: is this different than PINE (or any other terminal-based, interactive email client)?
Looks like mblaze but with extra steps<p><a href="https://github.com/leahneukirchen/mblaze">https://github.com/leahneukirchen/mblaze</a>
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.<p>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.<p>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.<p>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.<p>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.<p>Alas, a lot of professional interactions require HTML emails. I don’t want to come across as awkward nerd to everyone all the time.<p>*!:)
Q: Can I use this if I work at a Microsoft Teams enterprise org? Probably not, I'm guessing, but hoping there's a way to make that work somehow.