[MlMt] Do we need a better way to disable text/not-really-plain?

[Bill Cole]

On 15 Jan 2014, at 10:56, Rob McBroom wrote:

> On 15 Jan 2014, at 10:03, Bill Cole wrote:
[...]
>> Even worse: that non-standard "markup=markdown" parameter causes 
>> MailMate to translate what is labeled as "text/plain" into HTML which 
>> it then renders, instead of simply presenting the plain text.
>
> That’s sort of the point. ;-)

Which is why MM generates a multipart/alternative message with 
text/plain and text/html parts when one enables Markdown. Why it 
(sometimes?) then adds an empty text/plain part and wraps it all up as a 
multipart/mixed top-level type, I cannot explain.

>> This can include turning supposedly-plain text incantations into 
>> active (clickable) strings and hiding the original text. WHICH IS AS 
>> WRONG AS A TEXT/PLAIN RENDERER CAN GET!
>
> If the sender has claimed to be using Markdown, but then included 
> something that won’t render correctly, you should take it up with 
> them. (Can you give an example of something that looks “wrong”?)

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 (OTOH, if 
something evil grabbed control of the ability to send keystrokes with 
'Full Keyboard Access' enabled...)

>> Is the audience for a better default behavior and/or a more 
>> support-worthy switch larger than myself and the small crowd of very 
>> geeky people I've convinced to use MM? Put another way: is no one who 
>> doesn't work professionally with the problem of email as an attack 
>> vector even bothering to disable this misfeature?
>
> 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 *read*. So it’s 
> the best of both worlds.

That's a very subjective judgment 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. It may have a very 
marginal message size edge over tools that rendering plain text parts 
from generated HTML (Outlook) or a native rich text representation 
(Mail.app), but the only real message size (e.g. bandwidth and storage) 
win is to only send plain text.

> 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.

No, it does not. If it did, I would not be bringing this up. This is 
ONLY about the rendering of text/plain message parts. I thought I was 
pretty clear about that...

> In the meantime, I suppose you could use ⌥⌘U instead of ⌥⌘[.

Cmd-Opt-[ is usually inactive for me, since I prefer to read in plain 
text and have MM configured thus...

FWIW, I would much prefer for rare piece of pure text/html mail which I 
let into my mailbox to be shown in "raw" form by default and for the 
"raw" presentation to be sticky per-message so that problematic cases 
don't have to be switched every time they are looked at, but those are 
debates that Benny has already been through and I accept them as settled 
issues (although my boss has suggested a bribe to reopen them...)

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. My reasons for that preference range from pragmatic 
to cautious as well as paranoid and crypto-Luddite, but they are 
unlikely to be changed. I will spare you the arguments for why HTML 
email is fundamentally wrong and dangerous. It should not be hard to 
find my rants to that effect from 20ish years ago if you really want 
them, although time has proven them to be generally unpersuasive.