[HN Gopher] Himalaya: CLI to Manage Emails
___________________________________________________________________
Himalaya: CLI to Manage Emails
Author : xparadigm
Score : 245 points
Date : 2024-12-09 13:17 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| brink wrote:
| I love that logo.
| jarbus wrote:
| 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).
| throwthrow4567 wrote:
| you are in luck then, they just cut 1.0 4 hours ago =)
| jonstewart wrote:
| 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.
|
| https://en.m.wikipedia.org/wiki/MH_Message_Handling_System
| zimpenfish wrote:
| > I used and loved "mh" in college
|
| Same and also `nmh`. Loved how you could combine the various
| parts to make your own tools.
| mediumsmart wrote:
| me too - nmh and MH-E still learning though
| szajbus wrote:
| After testing many clients I learnt to stop worrying and just use
| Mail app.
| dewey wrote:
| 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.
| latchkey wrote:
| Another vote for mimestream! Was an early free user and love
| the app. Definitely worth supporting them.
| markatkinson wrote:
| 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.
| bovermyer wrote:
| I'm here too.
|
| 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.
| dotancohen wrote:
| I use many features of Thunderbird. And it works fine with
| outlook, even including calendaring, with the Owl plugin. It
| is a paid plugin, but it makes life much better.
| bovermyer wrote:
| I've tried to use Thunderbird several times over the years,
| and I always ended up going to something else. Maybe the UI
| bothered me, I'm not sure.
| kriops wrote:
| 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.
| pandemic_region wrote:
| My goal is always to have an empty inbox. So, emails that
| require some sort of action from my part but are not urgent I
| will snooze them (Gmail feature) to a later time. Email
| that's like "ok thanks for letting me know" and that's the
| end of that interaction, I will delete. Other stuff that
| requires more immediate attention I'll let it hang in the
| inbox for at most a few days and then try to act on them.
|
| I noticed that letting mails linger in sight in my inbox is
| energy draining or causes me to procrastinate.
| siva7 wrote:
| 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.
| krembo wrote:
| Kanmail turns your Gmail labels to a columnar kanboard, pretty
| useful in wide screens https://kanmail.io/
| tambourine_man wrote:
| 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.
| kiwijamo wrote:
| Outlook has the same searching issue. I often have to resort
| to manually eyeballing through my email archives to find what
| I'm looking for. Very annoying indeed.
| marcomourao wrote:
| MailMate did that for me.
|
| https://freron.com/
| oldpersonintx wrote:
| I can go a week now without receiving a single useful
| email...gmail or fastmail are fine
| skydhash wrote:
| 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.
| alberth wrote:
| I'm confused, it is called 'Pimalaya' or 'Himalaya'
| jarbus wrote:
| Pimalaya is the org, Himalaya is the mail client, AFAIK
| jedisct1 wrote:
| I still use mutt on a daily basis.
|
| Being able to select emails using regular expressions is super
| useful.
|
| IMAPFilter is also simple and powerful to quickly sort email.
| msravi wrote:
| What do you use to fetch email? mbsync keeps messing up the UID
| of emails with gmail.
| jedisct1 wrote:
| Just Mutt's IMAP support.
| 0fflineuser wrote:
| Personnaly, I use https://gitlab.com/shackra/goimapnotify ,
| you can add a `~/.config/imapnotify/{{ youremailaddresshere
| }}.yaml` config file for each of your email addresses and
| enable and start it as a systemd service with `systemctl
| --user enable ---now goimapnotify@{{ youremailaddresshere
| }}.service`
|
| 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: - INBOX
|
| ```
| svilen_dobrev wrote:
| > format
|
| indent it with 2+ spaces like this
| 0fflineuser wrote:
| Thanks!
| kmarc wrote:
| offlineimap does the job for me I use it with Gmail and owa
| (trough davmail)
| drwu wrote:
| 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.
| zerop wrote:
| Honest question - Why use interfaces like this, but not regular
| HTML client?
| tacomagick wrote:
| 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.
| smartmic wrote:
| 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.
| dmd wrote:
| > HTML breaks not only the philosophy but also many of the
| tools developed around email
|
| 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.
| choilive wrote:
| Perhaps LLMs can solve this somewhat? Not for email
| summarization - but to intelligently strip away all the
| HTML fluff and return a plain text version of the contents.
| myflash13 wrote:
| Apple Intelligence already does this in the line summary.
| abound wrote:
| FWIW, it's pretty straightforward to extract text from an
| HTML snippet without LLMs, I'm not actually sure if
| there's anything they'd do better than a simple HTML
| parser.
| berkes wrote:
| > 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.
|
| Is it? Whatsapp, Signal, Slack, Notion, ChatGTP, are
| amongst the apps I use daily - and used by many non-hacker
| daily, that's pretty much "text only". all support some
| (subset of) markdown, which is close to "plain text" than
| to "HTML" in editing and displaying.
|
| What I am trying to say is not that email should use
| markdown, or that HTML-email is bad or good. What I am
| trying to say is that there's clear and obvious proof that,
| in 2024, there's a need and use for "plain text". Even in
| tools that overlap with what email does.
| dzikimarian wrote:
| Slack is far from plain text:
| https://api.slack.com/block-kit/building
| tincholio wrote:
| The Slack blocks format is horrendous, and not very
| powerful.
| subsection1h wrote:
| > _Email is not plain text any more. We can 't pretend that
| it is or should be._
|
| I send plain text emails and this is a hill I will die on.
| :-)
|
| Do you not contribute to the development of any open-source
| projects that only accept patches via plain text emails
| sent to mailing lists (e.g., many GNU projects)?
|
| Here's a tip for anyone who sends plain text emails, or
| wants to, and has to deal with annoying normies who
| complain about undesirable wrapping[1] when viewing plain
| text emails on mobile devices with small screens: configure
| your mail client to allow lines in emails to be up to 998
| characters[2], which is longer than any paragraph you will
| likely write. I did this for my work email years ago.
|
| [1] https://www.arp242.net/email-wrapping.html
|
| [2]
| https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1
| bigstrat2003 wrote:
| I disagree that email should be plain text, but honestly I
| don't think that's really relevant to the question. I read
| the question as "why CLI instead of GUI", which I think is
| totally fair. Using a CLI email client instead of a GUI
| strikes me like using your feet to open jars - maybe you can
| do it, but it's _so much harder_ for no benefit.
| BeetleB wrote:
| > Using a CLI email client instead of a GUI strikes me like
| using your feet to open jars - maybe you can do it, but
| it's so much harder for no benefit.
|
| Eh? I used to use mutt and now use notmuch. Much simpler to
| use than, say, Outlook. Not sure what you're talking about
| being "harder".
| leephillips wrote:
| Absolutely right. Every GUI email client that I've tried
| is clumsy and slow. Mutt is elegant, powerful, and fast.
|
| https://lwn.net/Articles/837960/
| OJFord wrote:
| It just depends on the user. You probably also think cd &
| ls is so much harder than Finder or whatever.
| subsection1h wrote:
| > _As always with Emacs, the learning curve is a bit steep at
| first_
|
| 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.
|
| https://www.djcbsoftware.nl/code/mu/mu4e/
|
| https://www.emacswiki.org/emacs/mu4e
| smartmic wrote:
| The main reason I chose Gnus instead of mu4e or notmuch is
| that I did not want to sync all my mailboxes to local disk.
| What is perhaps not so well known is that IMAP provides its
| own server-side search engine. Searching mail with Gnus
| search queries [1] works really well, and I do not have to
| manage any overhead to get my mail synchronized, indexed,
| etc. In other words, everything I need for email is built
| into Emacs (or outsourced to the IMAP server) - no extra
| packages/software required.
|
| [1] https://www.gnu.org/software/emacs/manual/html_node/gnu
| s/Sea...
| beepbooptheory wrote:
| This. I kinda hate, but still understand, the general
| offlineimap/notmuch philosophy in this space. I am not in
| a bunker, I am not optimizing for a situation where I
| only have internet intermittently. I just don't want to
| leave emacs if I dont have to and want to be able to be
| quick and seamless between my code, mailing lists, rss
| feeds, org mode, and email in general. It was hard won,
| but I do get this with Gnus now. And yes, love how you
| can hijack almost all the IMAP/gmail niceties this way
| with a little bit of work, especially search.
|
| One thing I _have_ done is export the mbox archives of my
| old gmail accounts and keep them around in Gnus if I
| happen to need to search through old emails.
| floathub wrote:
| mu4e paired with mbsync is really amazing. All your email
| in Emacs, with super fast search, and the ability to
| integrate into things like org agenda.
|
| I found this guide particularly useful for setting things
| up and even dealing with annoying outlook/office365
| servers:
|
| https://brettpresnell.com/post/email/
|
| Does take a bit of doing, but so worth it.
| dredmorbius wrote:
| 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.
| mbreese wrote:
| 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.
| hk1337 wrote:
| This seems really nice. I wonder how it handles accounts with
| two-factor authentication, sms and yubikey.
| varunneal wrote:
| API Dev keys, e.g. https://developers.google.com/identity/proto
| cols/oauth2#1.-o....
| nixosbestos wrote:
| Sorry this is pretty low-value but I _love_ that organization
| name. Pimalaya. Cute and very fun to say.
| stabbles wrote:
| In Dutch it's very fun to say, but not cute ;) sounds like
| slang for the male genitalia.
| djha-skin wrote:
| 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].
|
| 1: https://github.com/djha-skin/git-receive-mail
| pydry wrote:
| Looks nice. No JMAP though :/
| tempfile wrote:
| Looks like mblaze but with extra steps
|
| https://github.com/leahneukirchen/mblaze
| 38 wrote:
| last release 2017, good game. also only works on Windows with
| Linux emulator.
| codetrotter wrote:
| No? Version 1.3 was tagged in the repo September 13 this
| year.
|
| 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.
| cfiggers wrote:
| 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.
| rubicks wrote:
| I have been looking for something like this. Got a link to your
| project?
| xyst wrote:
| 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.
| szundi wrote:
| I liked mutt, but this seems promising as well.
| JeremyHerrman wrote:
| Is anyone using local LLMs to manage their email? This seems like
| it could be helpful to hook that up.
| MikeTheGreat wrote:
| Genuine question - the HN title says "CLI to..." but looking at
| the GitHub repo I don't see any CLI-centric documentation.
|
| I do see $ himalaya envelope list --account
| posteo --folder Archives.FOSS --page 2
|
| 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 wrote:
| Himalaya is not interactive: while Pine is a TUI, this is a
| CLI. Very useful to integrate emails in scripts easily.
| zokier wrote:
| The built release packages have full set of man-pages for you
| to familiarize with.
| ape4 wrote:
| https://man.archlinux.org/man/himalaya.1.en
| alchemist1e9 wrote:
| How does this compare to old school mblaze tools?
| rs812005 wrote:
| lol
| ferdws221133 wrote:
| Hi
| taylorbuley wrote:
| I use alpine over at sdf.org. I'd love to use this instead.
| jxf wrote:
| 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.
| teruakohatu wrote:
| 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.
| stackskipton wrote:
| 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.
| michaelmior wrote:
| I haven't tried, but the README mentions Office 365 and OAuth,
| so perhaps?
| delusional wrote:
| 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 :)
| aynawn wrote:
| 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.
|
| Edit: there is a separate tool for this for gmail
| https://github.com/mbrt/gmailctl
___________________________________________________________________
(page generated 2024-12-09 23:00 UTC)