[MlMt] Show HTML source doing The Wrong Thing

[Seebs]

On 6 Dec 2012, at 3:12, Benny Kjær Nielsen wrote:

> On 6 Dec 2012, at 5:24, Seebs wrote:
>
>> It is pretty much a safe bet that, no matter what I *do* want, "show 
>> me the HTML that is used internally by Mailmate to render the plain 
>> text part of this message, but which does not actually occur in the 
>> message in any way" is not it.
>>
>> I sometimes get mail where the sender has very carefully added an 
>> EMPTY plain text alternative. Which I get by default because I tend 
>> to prefer plain text to begin with. If I accidentally select "Show 
>> HTML Source" instead of "Message Body Parts -> HTML", then... Whoops! 
>> I get something that looks like HTML, so I might mistakenly believe 
>> there is actually some relationship between it and the HTML message, 
>> but which is not actually part of the message.
>
> One possible solution: The “Show HTML Source” menu item is 
> removed. Instead it is an alternative menu item shown instead of 
> “Show Raw Message” when holding down ⌃, that is, the shortcut 
> becomes ⌃⌥⌘U.

Hmm.

For an HTML-only message, there are three useful states: Rendered HTML, 
HTML source, raw message.

For a text-only message, there are two useful states: Rendered text, raw 
message.

For a text-or-HTML message, there are four useful states: Rendered plain 
text, rendered HTML, HTML source, raw message.

Also I note that 95% or more of the time, the only value of "raw 
message" is "shows complete headers as selectable text". (I would much 
like the ability to copy/paste header lines from the regular header 
display.)

So I think... "Show HTML source" should either not exist, or exist only 
when an HTML message is being displayed. Possibly,

> It is mainly useful when working on a custom stylesheet for the 
> message view. Probably a very low percentage of users :-)

Oh!

I guess there IS a case where "show HTML source" would be useful for 
plain text. But it might also make sense to distinguish, and to consider 
that a distinct option from "show HTML source" for an HTML part.

Maybe when looking at text parts, it could be named "Show MailMate HTML 
wrapper" or something similar, to indicate that we are talking, not 
about the HTML in the message, but about the HTML mailmate's using to 
render it.

> Opinions?

Well, now that I know about the custom style sheet option, I can see a 
benefit to this. I think the main thing is, it probably wants to be 
less-visible than "show HTML". If anything, I think it might maker sense 
to make HTML/text toggles more obvious and more visible; for instance, 
something in the header-display area that is only present when a message 
has alternatives, so there could be a little button which appears and 
says (Show HTML) or (Show Plain Text).

Right now, if I'm looking at text (or the lack of any text), the only 
way for me to tell that there might be more (or less) data in the HTML 
is to go to the View menu, then select the never-greyed-out "Message 
Body Parts" submenu, and look to see what it shows. I am not sure I have 
ever seen a message with more than two alternatives for its message 
body... So providing a visible indicator of "there is probably something 
else to see" might make sense.

As might an option for "show text part by preference, unless text part 
is completely empty and HTML part isn't".

So thinking about it:

1. Would like a "show all headers" distinct from "show entire message 
completely raw".
2. Maybe "show HTML source" should turn into "show unprocessed body", 
wherein HTML is rendered as source, and quoted-printable (which is odd 
because everything I've heard people say about it is unprintable) gets 
shown still-mangled, for instance. Possibly even base64 crud. :)
3. An option for "show the HTML wrapping MailMate is doing to this text" 
is useful, but should probably not be in the same category as "show the 
source of this HTML message".
4. The more I interact with this program, the more amazed I am that 
anyone has ever successfully written a mail client, because every time I 
suggest something that sounds simple it turns out to be a fairly complex 
territory that I had never been aware of.

-s