51–60 of 102 posts
After testing many clients I learnt to stop worrying and just use Mail app.
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.
Earlier quoted context omitted.
> 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 ca…
> 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 displa…
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).
Earlier quoted context omitted.
> 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 ca…
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.
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.
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…
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…
> 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 ca…
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
After testing many clients I learnt to stop worrying and just use Mail app.
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.
Honest question - Why use interfaces like this, but not regular HTML client?
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…
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.
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.