<div class="markdown">
<p dir="auto">On 15 Jan 2014, at 15:02, Bill Cole wrote:</p>

<blockquote>
<p dir="auto">Which is why MM generates a multipart/alternative message with text/plain and text/html parts when one enables Markdown.</p>
</blockquote>

<p dir="auto">True, I had forgotten about that, but the sender can omit the HTML part without turning of Markdown, as Benny said.</p>

<blockquote>
<p dir="auto">Most critical is URLs. If I wanted URLs automatically hidden from me, I wouldn't have MM set to prefer plain text and maybe I wouldn't be using MM at all. I'm a bit disappointed that they are made active (i.e. "clickable") without any clear way to turn that off, but I am well-trained to avoid the habits that make that really risky</p>
</blockquote>

<p dir="auto">Something that might help is a custom style sheet that makes links really stand out. (I forget what they look like by default.)</p>

<blockquote>
<p dir="auto">(OTOH, if something evil grabbed control of the ability to send keystrokes with 'Full Keyboard Access' enabled...)</p>
</blockquote>

<p dir="auto">Clicking links in e-mail would be the least of my worries in that situation. :-)</p>

<blockquote>
<blockquote>
<p dir="auto">I can only speak for myself, but I think the implementation is great. Plain text is easier to write, nearly universally portable, and uses less bandwidth, but (rendered) HTML is much nicer to <em>read</em>. So it’s the best of both worlds.</p>
</blockquote>

<p dir="auto">That's a very subjective judgment</p>
</blockquote>

<p dir="auto">I was clearly trying to pass it off as objective truth when I said “I can only speak for myself”.</p>

<blockquote>
<p dir="auto">with an embedded fallacy behind the conclusion. Because any reasonable HTML mail composer creates a multipart/alternative container for the HTML version of the message and a plain text equivalent, the fact that you happen to compose in Markdown (which gets used as the plain text version) uses more bandwidth than if you were to use something that sent pure HTML.</p>
</blockquote>

<p dir="auto">Absolutely right. Like I said, I had forgotten about the optional HTML part that gets sent along with the Markdown. I have it enabled, since most of the people I deal with are using Outlook.</p>

<blockquote>
<blockquote>
<p dir="auto">The only thing I would change is that switching to the plain text alternative should show the original Markdown as written. If that were the case, I think the “Prefer plain text” Viewer preference would make MailMate behave the way you want.</p>
</blockquote>

<p dir="auto">No, it does not. If it did, I would not be bringing this up.</p>
</blockquote>

<p dir="auto">I’m aware of that. I thought it obvious that I was describing desired behavior, not current behavior.</p>

<blockquote>
<p dir="auto">I'm not really open to arguments that I shouldn't want message parts labeled as plain text to be displayed as plainly as possible rather than parsed for markup.</p>
</blockquote>

<p dir="auto">You’re not getting one. Not from me, anyway.</p>

<p dir="auto">This is exactly the “desired behavior” I laid out. When viewing the plain-text part (whether by default with “Prefer plain text” or by ⌥⌘[), there shouldn’t be any parsing.</p>

<p dir="auto">(In the case where there is <em>only</em> a text part, and it’s identified as Markdown in the <code>Content-type</code> header, clients that support automatic rendering should behave as if there are two parts. That would allow us to switch between the two representations and/or see the preferred one by default.)</p>

<blockquote>
<p dir="auto">I will spare you the arguments for why HTML email is fundamentally wrong and dangerous.</p>
</blockquote>

<p dir="auto">I know them. I used to make them. But when it became clear that some sort of “rich” e-mail was here to stay, and MS-TNEF was one of the more common ways to do it, HTML seemed pretty good all of a sudden.</p>

<p dir="auto">-- <br>
Rob McBroom<br>
<a href="http://www.skurfer.com/">http://www.skurfer.com/</a></p>

</div>