Himalaya: CLI to Manage Emails • Hacker News Board

Re: Himalaya: CLI to Manage Emails

#81

Post by smartmic » Mon, Dec 09, 2024, 9:02 PM UTC

subsection1h wrote: post #59

smartmic wrote: post #18

Earlier quoted context omitted.

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 Gnu…

> 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

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/gnus/Sea...

Re: Himalaya: CLI to Manage Emails

#82

Post by aynawn » Mon, Dec 09, 2024, 9:11 PM UTC

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

Re: Himalaya: CLI to Manage Emails

#83

Post by floathub » Mon, Dec 09, 2024, 9:27 PM UTC

subsection1h wrote: post #59

smartmic wrote: post #18

Earlier quoted context omitted.

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 Gnu…

> 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

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.

Re: Himalaya: CLI to Manage Emails

#84

Post by beepbooptheory » Mon, Dec 09, 2024, 9:34 PM UTC

smartmic wrote: post #81

subsection1h wrote: post #59

Earlier quoted context omitted.

> 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

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…

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.

Re: Himalaya: CLI to Manage Emails

#85

Post by bandie91 » Mon, Dec 09, 2024, 11:02 PM UTC

jonstewart wrote: post #4

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

shameless plug: i wrote emlv[1] (EMaiL Viewer) in the same mindset. it displays raw email files on the terminal.

[1] https://codeberg.org/hband/gemlv#emlv

Re: Himalaya: CLI to Manage Emails

#86

Post by cfiggers » Mon, Dec 09, 2024, 11:54 PM UTC

rubicks wrote: post #56

cfiggers wrote: post #55

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…

I have been looking for something like this. Got a link to your project?

Hey there. This project isn't posted publicly anywhere at the moment—it's a very idiosyncratic one-of-one sort of deal.

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.

[0] https://textual.textualize.io/

[1] https://hylang.org/

Re: Himalaya: CLI to Manage Emails

#87

Post by broken-kebab » Tue, Dec 10, 2024, 1:05 AM UTC

bigstrat2003 wrote: post #36

smartmic wrote: post #18

Earlier quoted context omitted.

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 Gnu…

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.

I think it's not the question. One can continue using GUI, and value CLI for its flexibility. E.g. if I'd like to script some routine task, availability of a CLI tools will make it a breath. In the average case of GUI it's either impossible altogether, or requires some ugly user input simulation. Which is like using your feet to open jars - to borrow your comparison

Re: Himalaya: CLI to Manage Emails

#88

Post by e12e » Tue, Dec 10, 2024, 1:41 AM UTC

0fflineuser wrote: post #22

msravi wrote: post #14

Earlier quoted context omitted.

What do you use to fetch email? mbsync keeps messing up the UID of emails with gmail.

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:…

> tlsOptions:

> rejectUnauthorized: false

Means trust any cert?

Re: Himalaya: CLI to Manage Emails

#89

Post by gorgoiler » Tue, Dec 10, 2024, 1:42 AM UTC

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.

*!:)

Re: Himalaya: CLI to Manage Emails

#90

Post by goku12 » Tue, Dec 10, 2024, 3:42 AM UTC

bigstrat2003 wrote: post #36

smartmic wrote: post #18

Earlier quoted context omitted.

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 Gnu…

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.

As another commenter pointed out, CLI/TUI isn't that hard. In many cases it's easier than GUI ones. But I have a different purpose. I can configure different pieces (imap for incoming, smtp for outgoing, notmuch & afew for tagging and search, etc) and use it uniformly from a variety of different programs including git and emacs. Not very simple, I must admit. But it's a personal choice. It works very well for my use cases, including realtime full mail backup and offline use.