> Rich text features desirable for end users include things like inline images, bold or italicized text, and so on. However, the tradeoff isn't worth it. Images can simply be attached to your email, and you can employ things like asterisks, /slashes/, _underscores_, or UPPERCASE for emphasis.
Well, why bother writing his own post in rich text then? He has headings, bold, links, grey font at the bottom, image.
Don't get me wrong - for high security systems/environments, plaintext is way to go. For everyday life use cases I prefer html. Although with Markdown rendered text I would be pretty happy. And enough for author to cover his post sans the green/red boxes and grey text.
But emails can be reference documents too! In fact I would argue most work emails that are longer than a few lines are a reference document of some sort.
Then you are better off using some format that can stand alone as a file such as PDF. If it is a reference document that is intended to be edited on an ongoing basis it is better to use something like a wiki. Having to root around in your email to find a reference document is pretty inefficient and annoying.
All of the reasons given against HTML emails hold at least equally well against PDF: it's a vector for phishing and tracking, ripe with client vulnerabilities, less accessible and not displayable on a terminal. For me as a reader having to read both an E-Mail and the attached PDF is also annoying, and many people will simply skip reading the PDF.
why not let people syntax highlight the way they want? some people dislike syntax highlighting, some like high contrast highlighting, some like blue-tinted highlighting, etc. why do you get to decide for everyone what colour strings should be?
send the plaintext code snippet and they'll decide.
For the life of me I can’t remember the syntax for a particular thing I do in the JavaScript console at work. Someone showed me the trick in an email about seven years ago and about once a month I need to do this thing so I search my inbox for the email so I can remember the syntax.
It might be "easier and faster" to send an email than to, for instance, upload to a dedicated snippet manager, but literally everything after than that is slower and more difficult.
Exactly, work mailboxes are a treasure trove of automatically-archived information. I'd argue that these days, emails form more of a "knowledge base" than any other single repository of information for most organisations.
This is very true and yet the search tools supplied with these knowledge bases are terribly inadequate. Is there a better, standalone tool out there for turning email archives, from multiple sources, into a usable database with a powerful query language?
Not sure if that's what you're looking for, but you could use notmuch[0]. Haven't used it a lot, but I think it can import an mbox? Maybe you can merge multiple mboxes together?
I looked into that a few times, just haven't had the patience to get through the setup process. Maybe I'll get it done this time. There goes my afternoon :)
I was keeping an eye on this in the hope that someone had a good answer for it. What features would you consider adequate for this kind of email search? At the moment I just have everything in Thunderbird and it does a passable full-text search on a ~5gb mailbox but I haven't experimented with anything fancier.
email is a terrible place to keep reference documents.
"where's the information on that?" "oh, you should have it in your email somewhere. I think I got one a few months ago about it"
no. just. no. If you care _at all_ about your reference documents you get them out of email ASAP.
And that's ignoring that anyone can delete old emails and thus not have what you considered a reference doc but they just considered old mail. Or that the server could loose your emails and no-one has they synced locally these days.
> email is a terrible place to keep reference documents.
Newsgroups are better in that regard. You can reference the message using the message-id value. A lot of newsgroups would have FAQS posted every 30 days or so. A reference document that's periodically updated could be sent the same way.
That's pretty much a non-sequitur. HTML is better in email as well as "reference documents" according to the opinions of many. You don't like thing. Okay.
RFC 822 is plaintext. That's a reference document. Don't see why HTML would be an argument for a reference document. In fact, tex is a good format for reference documents, it diff's well and can produce .ps/.pdf outputs among others.
Before MIME was common, people used to insert uuencoded data within the email message. IIRC, certain email clients would display the decoded content inline with the surrounding text.
Email is supposed to be easy to quote, just like you’ve used a block quote in your comment. I assume it’s obvious that rich text is difficult to quote, but a quick explanation is that the invisible formatting characters used to represent rich text behave inconsistently when re-contextualized for a quote.
Since when? I have never heard anyone say this in my entire life. I want emails to look good. So I guess people are different and we can't draw a simple conclusion about what people want from email?
I’m not sure what you’re saying here. Is it that you’ve never heard of the concept of quoting a passage of an email? Or are you saying “sure people do that, but it doesn’t matter if it’s easy”?
Or perhaps the parent commenter is part of the lost generation of email users that never properly used quoted replies in email conversations. And this is not necessarily an comment on the age of the parent commenter, but rather about what email programs were common at the time. I blame Outlook mainly for this, but Gmail hasn’t done much to help here either.
The use of quotes in replies is also part of the article and is definitely a better way to go with bottom replies than the current default of top replies.
It would be easy if there were a single accepted way to quote in rich text. (Seriously, the block quote tag has been around for eternity!) I don't think it works well in plain text either.
It's far better than trying to keep count of how many ">" are in play, and deal with the vagaries of soft linebreaks and hard linebreaks and wrapping of plaintext.
Well, why bother writing his own post in rich text then? He has headings, bold, links, grey font at the bottom, image.
Don't get me wrong - for high security systems/environments, plaintext is way to go. For everyday life use cases I prefer html. Although with Markdown rendered text I would be pretty happy. And enough for author to cover his post sans the green/red boxes and grey text.