6 ms·

Honest question - Why use interfaces like this, but not regular HTML client?

by zerop 2y ago

tacomagick 2y ago
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 2y ago
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 2y ago
  > 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 2y ago
    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.
    - _1tem 2y ago
      Apple Intelligence already does this in the line summary.
    - abound 2y ago
      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.
    - ninjin 2y ago
      It is a solved problem. Here is a solution that requires something of the order of 1,000,000th of the resources of your proposed idea, no subscription, and runs so fast that you would not even notice it on a machine from 20 years ago: > grep text/html ~/.mailcap text/html; lynx -width 72 -assume_charset=%{charset} -display_charset=utf-8 -dump %s | sed 's|^ ||'; nametemplate=%s.html; copiousoutput If you want something more modern: text/html; webdump -dli < %s | sed 's/^ //g'; needsterminal; copiousoutput
      - pabs3 2y ago
        Whats webdump?
        ninjin 2y ago
        https://codemadness.org/git/webdump https://codemadness.org/git/webdump
  - berkes 2y ago
    > 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.
- bigstrat2003 2y ago
  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 2y ago
    > 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 2y ago
      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/ https://lwn.net/Articles/837960/
  - OJFord 2y ago
    It just depends on the user. You probably also think cd & ls is so much harder than Finder or whatever.
  - broken-kebab 2y ago
    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
  - goku12 2y ago
    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.
- subsection1h 2y ago
  > 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.djcbsoftware.nl/code/mu/mu4e/ https://www.emacswiki.org/emacs/mu4e https://www.emacswiki.org/emacs/mu4e
  - smartmic 2y ago
    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/Search-Queries.html https://www.gnu.org/software/emacs/manual/html_node/gnus/Sea...
    - beepbooptheory 2y ago
      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 2y ago
    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/ https://brettpresnell.com/post/email/ Does take a bit of doing, but so worth it.
dredmorbius 2y ago
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 2y ago
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.

Honest question - Why use interfaces like this, but not regular HTML client?

by zerop 2y ago

Honest question - Why use interfaces like this, but not regular HTML client?

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 2y ago

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 2y ago
> 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 2y ago
  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.
  - _1tem 2y ago
    Apple Intelligence already does this in the line summary.
  - abound 2y ago
    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.
  - ninjin 2y ago
    It is a solved problem. Here is a solution that requires something of the order of 1,000,000th of the resources of your proposed idea, no subscription, and runs so fast that you would not even notice it on a machine from 20 years ago: > grep text/html ~/.mailcap text/html; lynx -width 72 -assume_charset=%{charset} -display_charset=utf-8 -dump %s | sed 's|^ ||'; nametemplate=%s.html; copiousoutput If you want something more modern: text/html; webdump -dli < %s | sed 's/^ //g'; needsterminal; copiousoutput
    - pabs3 2y ago
      Whats webdump?
      - ninjin 2y ago
        https://codemadness.org/git/webdump https://codemadness.org/git/webdump
- berkes 2y ago
  > 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.
bigstrat2003 2y ago
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 2y ago
  > 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 2y ago
    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/ https://lwn.net/Articles/837960/
- OJFord 2y ago
  It just depends on the user. You probably also think cd & ls is so much harder than Finder or whatever.
- broken-kebab 2y ago
  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
- goku12 2y ago
  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.
subsection1h 2y ago
> 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.djcbsoftware.nl/code/mu/mu4e/ https://www.emacswiki.org/emacs/mu4e https://www.emacswiki.org/emacs/mu4e
- smartmic 2y ago
  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/Search-Queries.html https://www.gnu.org/software/emacs/manual/html_node/gnus/Sea...
  - beepbooptheory 2y ago
    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 2y ago
  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/ https://brettpresnell.com/post/email/ Does take a bit of doing, but so worth it.

dredmorbius 2y ago

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 2y ago

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.