Emacs Should Support HTML Mail
This article suggests that it is a good idea that emacs's mail facilities (rmail, gnus, vm) support receiving and reading HTML mail.
Tim wrote: «In general, HTML in mail messages is a bad thing.».
HTML in email is a very good thing.
From the social point of view, HTML is also far more useful, and people want the ability to have colored text, embed images, attachments. I don't have stats on this, but it is my guess that some 80% email traffics today, are in HTML. Human animals, collectively, want it.
Arguably, another format, such as [ RTF ] [ https://en.wikipedia.org/wiki/Rich_Text_Format ] that WAS espoused by Apple computer's email software [ Mail ] [ https://en.wikipedia.org/wiki/Mail_(application) ] for a number of years in the early 2000s, is a better tech than HTML for rich text in email. But for whatever social reasons it didn't catch on. Html is the de facto standard today for rich text in email.
Also, as i mentioned before, tools used by tech geekers usually have 5 or more so years lagging in catching up with any tech that are being adapted in the commercial world. For example, HTML email has basically became the standard in Microsoft since maybe 2002, and HTML is widely supported or in fact default format for commercial web based service provider since many years ago too.
Convenient Wikipedia links: [ HTML e-mail ] [ https://en.wikipedia.org/wiki/HTML_e-mail ].
Tech geekers often have a irrational fetish towards plain text email. I wrote a essay back in 2002 detailing my thoughts on this: See: Plain-Text Email Fetish.
This essay is originally a post on gnu.emacs.help, At http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/9d9049c471d8764a.
Priority Of Adapting HTML Mail
I believe that emacs should adapt the ability to send and receive HTML mail, however, i do not think it is a priority. The above essay was originally just a spontaneous discussion on “gnu.emacs.help”.
Among emacs's potential improvements, there are several that are far more easier to fix and has far more impact than the ability to handle HTML mail. For example, see Modernization of Emacs.
Even if we were to put priority on improving emacs's email feature, it would be far more pertinent to create a robust interface for web based email, because, today vast majority of people reads email online with mail service providers such as [ Google Mail ] [ https://en.wikipedia.org/wiki/GMail ], [ Yahoo! Mail ] [ https://en.wikipedia.org/wiki/Yahoo!_Mail ], Microsoft's [ Hotmail ] [ https://en.wikipedia.org/wiki/Hotmail ], using a web browser. Few are actually using a standalone [ Email client ] [ https://en.wikipedia.org/wiki/Email_client ]. Among programers, there are even fewer who actually still use a text-based email client. Most people who uses emacs do not use its email client features.
- Simple Changes Emacs Should Adopt
- Why Emacs Keys are Painful
- Ban Scratch Buffer
- M-x vs Alt+x Notation
- Menu Idiocy
- Mode Line Problem
- cua-mode Problem
- Inconsistency of Search
- grep in emacs Pain
- Problems of describe-mode
- Problems of Emacs Manual
- Emacs Manual Sucks by Examples
- kill-buffer Problem
- Emacs Spell Checker Pain
- Form Feed ^L
- Single Key Delete Whole Line
- Emacs HTML Mode Sucks
- Emacs No View Image on Windows
- HTML should replace Texinfo
- Support HTML Mail
- Problems of “man”
- Emacs Lisp Mode Syntax Coloring Problem
- Emacs AHK Mode Problems
- Ban Syntax Table
- Make elisp-index-search use Current Symbol
- Texinfo Invalid HTML
- Disappearing FSF URLs, 2006
- Emacs Manual Node Persistency Issues
- Emacs: dired-do-query-replace-regex Replace ALL (fixed)
- Problems of Emacs Supporting Obsolete Systems
- Elisp: Function to Copy/Delete a Dir Recursively (fixed)
- CommonLisp/SchemeLisp Emacs
- Text Editors Popularity
- Cursor Movement Behavior Survey
- Letter-Case Commands Problem
- Select Line/Block/Quote, Extend
- isearch Current Word
- Reformat Line Wrap