So, I guess people really do use html mail now. I'm a little sad, but not surprised. I do find it a little bit ironic converting markdown (a format for structured plain text, allowing for easy quoting, in-line replies etc) to html.
That aside, I can understand the frustration with web interfaces, and if committed to using gmail, why not have a nice interface for composing mails at least?
My current pet peeve with google interfaces, are the text-editing boxes on g+ -- which are not text-boxes, and so doesn't work with "it's all text" -- and also breaks cut'n'paste for long sections of text. So I end up editing a text-file in vim, then copying section by section in ordert to post into g+ communities. Sigh.
I dislike that email, which predates the web, adopted html. And quite frustrated that many clients do not attach an equivalent plain text version of the email.
I thought this would be a problem, but frankly piping in everything into w3m makes it surprisingly easy to stay plain text only if desired.
At the risk of being accused of being on your lawn, what do you dislike about email's adoption of HTML? I'm old enough to remember the walled garden "mail" of Prodigy and early AOL, and the advent of inter-network electronic mail, but I feel like HTML is a major contributing factor to taking email from something people didn't realize they had ("AOL gives me e-mail?") to something we can't live without now.
I think you are setting the bar a little too high. It seems to me like there is quite a bit of mail that benefits from HTML. Superscripts, subscripts, italics, bold and colored text (used in moderation), inline images (used in moderation) can be really useful when discussing concepts that aren't easily reduced to characters.
Suppose your email would benefit from some mathematical formulas. You can do the old standby and drop into latex math mode, but the person on the other end of the email might not understand what you mean by
\sum_{n=1}^k\,\frac{1}{n} \;=\; \ln k + \gamma + \varepsilon_k < \ln k + 1
much easier and clearer to use LaTeXiT or something similar and copy/paste in an inline image with the formula correctly formatted.
Or, say you are a taxonomist. Italics in species names are not just a stylistic choice, they also convey additional meaning. For example in
Epilobium ciliatum Raf. subsp. watsonii (Barbey) Hoch & P.H. Raven f. rosa
the italics show what parts of the full scientific name refer to the species and what parts refer to authors or levels of taxonomic organization (subspecies and form). You can't do that with plain text (you could of course do it with markdown, though)...
plain text is sufficient of course; but sometimes the additional bells and whistles of HTML really are useful.
I generally think /italics/ and bold, quoting "> ", ">> " etc work fine. In addition to utf-8 encoding, you've covered a lot of ground (for English-speakers, utf-8 might seem like a luxury, and of course, if you demand unicode support you're beyond "basic" plain text -- it is however what I mean when I say I prefer plain text emails).
Formulas an illustrations can usually just be appended (and while they won't be shown in-line most clients will display images (and those choosing clients that don't won't really complain), but yeah, if you need multimedia you need multimedia.
Now, I don't really see how an image of an equation is really enough -- if you're working with someone, you'd want them to be able to quote you, reply to you -- and most importantly, tweak your work (edit your equations). I'd argue such (genuinely rich documents) don't really belong in email. Use a wiki or something (and then you can email wiki-markup...).
In short, I'm not convinced all the down sides and added complexity of html mail is worth the hassle.
Are rich documents and hypertext (hypermedia) a good idea? Yes. Does it imply a truly object oriented system, essentially mailing each other runnable smalltalk code? Yes. Will that be secure? No. Will that be standardized? Not by the looks of things. This is essentially why office suites are a source of security holes and incompatibilities. And web apps (though differently).
My default for gmail is sending plain text, but sometimes I will flip to html for bullets or if I am sending a project plan or some similar that I want formatted nicely.
But yeah, most of the time text I think that plain text works better.
(I suppose I could use some crazy utf-8 characters, but I generally don't).
More to the point - if layout is important, I'm more likely to mail someone a pdf - but I usually don't because I usually expect people to read mail in their mail reader. And that means respecting however they prefer to read mail (eg: background/foreground colour, font, quote-styling etc).
Then again, that used to be the way of the web too -- and now all browsers have basically given up on user stylesheets (and we all know we need to "reset" the CSS for a baseline for our "fancy" web page layouts...).
All that said, I'm not horribly against simple html in mail: No css, em/strong, h1..6, in-line images (with images bundled with the mail for privacy and off-line reasons) -- basically "rich text". But with a text/plain part!
The patched version of It's All Text! mentioned in the submitted blog post let's you edit the non-textarea textboxes on Google+.
(The blog post mentions my patch, but it was actually Github user patjak who got IAT! working with non-textareas, all I did was remove a bit of patjak's code to make the HTML passthrough unmodified to the editor.)
Oh, that's nice. Is the bundled up extension available for download? (I can't seem to find any instructions for that, but maybe I'm just not looking hard enough).
Thanks for pointing it out! (I do have some bad memories with things like these trying to keep up with a non-published, no-promisies-against-change, defacto-api like g+ edit-fields though...)
I don't think there is a bundled extension available. I personally don't know how to make one. To use it on my computer I just opened up the installed vanilla extension (turns out they are just compressed bundles of source code) and edited the files I found there by hand.
This tool involves switching to Emacs to compose a message body, while doing all of your mail interactions with the web interface. Once composing is done, the content is sent to the browser. Optionally, you can write in markdown, processing that before the hand-off back to the browser.
It would be possible to eliminate the back-and-forth jumping, just doing everything in Emacs, using the recently-announced Gmail API[1]. To the author, is this something you've considered doing? I'd use something like that.
This actually sounds nice and not too difficult. Thanks for pointing it out. Unfortunately, I barely have time to improve my existing packages anymore, let alone create new ones.
So yes, it is something I've considered, but I wouldn't hold my breath if I were you.
I have been using "Gmail old compose"[1] together with
"It's all text" / "Edit with Emacs" to achieve the
same effect. With the old compose, there's no need to
convert to/from HTML: email body is just text.
I suggest you take a look at sup (http://supmua.org/). Its goal is to transpose the gmail experience on your terminal.
I've been working with the maildirroot branch [0] which mimics the IMAP installation of GMail, so you can use a standard OfflineIMAP to sync between your computer and GMail, and still use all the power of tagging/archiving/searching on your computer.
Oh and it has a few niceties, the most important one to me being native support of gpg.
Once you've looked at sup, take a look at Notmuch (http://notmuchmail.org/), which separates the search/indexing of incoming messages from the mail composition from sending/receiving. As a spiritual sup successor, it has a few nice clients for the command line (bower?) and various editors (Emacs, maybe a vim client too)
Gmail's implementation of IMAP is quite broken (and the XMPP/Jabber one too!).
But you can achieve a local setup which rivals with Gmail by combining mutt and/or notmuch/mu and isync (mbsync). And it's quite possible to keep it sync'ed with Gmail, although there might be some rough edges.
Personally, I don't thing tags are that useful if you have a fast and expressive local search engine like notmuch or mu (xapian-based), but YMMV.
It didn't work quite like I wished right "out of the box", but it wasn't too hard to hack it to behave more according to my wishes. Three cheers for open source software!
I still use MH-E + nmh in Emacs on Linux, and I had phantasies of using it with IMAP and the GNU version of nmh, but I've never really seen someone say it works. Anyone?
The lack of imap IDLE is a killer for me. I don't want to poll the server all the time, but I want to be notified of email ASAP.
Offlineimap also breaks with imap IDLE, regrettably.
That's a good question. It's one of those things that I remember being complicated, but when I look over my configuration, it seems pretty damn straightforward. I guess the fact that Channels and Groups share a namespace irritated me?
Anyway. It's a great piece of invisible, blue-collar software.
I love mu as a mutt backend. The contact search is brilliant for address completion. However, it seems to lack thread reconstruction abilities like notmuch?
Notmuch, on the other hand, lacks contact search. This is a bit silly, given that both are frontends to xapian.
Recent versions of mu do have some thread-reconstruction support. On the command line, you can use the --include-related parameter to 'mu find' to return whole threads when any message in the thread matches the search (rather than returning only the matching message). The mu4e emacs frontend also uses that in various ways.
I've only been using mu for about a week, so I'm not any kind of expert. On the other hand I did just spend a bunch of time reading about both mu and notmuch to try to pick one (and picked mu), so I can list some of what I came across, since it's pretty fresh in my mind.
The main difference is in data models: mu uses Maildirs for message filing, while notmuch uses the Xapian db for message tagging. mu uses a traditional file-into-folders paradigm, where the folders are on-disk Maildir folders. You file messages by moving them. notmuch on the other hand uses a Gmail-style message-tags paradigm, where tags are stored in the Xapian db and the original files are treated as immutable. Messages on disk are never touched/moved; all changes to message state (even "deleting") are just tags in the db.
IMO that makes notmuch more flexible: a tag can be anything, with user-defined tags and "built-in" tags like sender and subject being treated similarly. mu on the other hand treats the Maildir files as the canonical db, so its index includes only data from there: the message headers and content, the folder, etc. (no user-defined tags). An advantage of that is that it makes mu more interoperable, since other clients can read the Maildir structure without having to know about mu. It also makes mu feel a bit "safer" to me, since the Xapian db is purely a search index that can be regenerated at any time from the Maildir files with no data loss. On the other hand, notmuch's choice to never modify/delete/touch your original mail files is safer in a different way.
Other differences:
- mu is mainly developed by one developer (HN user djcb), while notmuch is more of a group effort. Some pros and cons to each there.
- mu has a very nice proper manual. notmuch's documentation isn't bad, but it's not a nice proper manual.
- mu collects a contact db by default. I believe there's also a solution for notmuch to do that though.
- notmuch has a procmail-replacement story, https://github.com/teythoon/afew, whereas many mu users still use procmail for initial message handling
- I like mu4e, the emacs mail client that's developed together with mu. I haven't tried integrating either mu or notmuch with mutt or another client, though, so I don't know how they compare on that.
That aside, I can understand the frustration with web interfaces, and if committed to using gmail, why not have a nice interface for composing mails at least?
My current pet peeve with google interfaces, are the text-editing boxes on g+ -- which are not text-boxes, and so doesn't work with "it's all text" -- and also breaks cut'n'paste for long sections of text. So I end up editing a text-file in vim, then copying section by section in ordert to post into g+ communities. Sigh.
[1] https://addons.mozilla.org/en-US/firefox/addon/its-all-text/