[MlMt] To *not* generate HTML

[Pete Resnick]

On 2 Jul 2024, at 3:05, Benny Kjær Nielsen wrote:

> On 1 Jul 2024, at 20:59, Pete Resnick via mailmate wrote:
>
>> On 1 Jul 2024, at 4:57, Benny Kjær Nielsen wrote:
>>
>>> On 29 Jun 2024, at 4:31, Pete Resnick via mailmate wrote:
>>>
>>> Yes, this has not been an option for a long time. The original idea 
>>> was that receiving email clients could, when possible, just convert 
>>> Markdown to HTML when needed for display, but this has all kinds of 
>>> unresolved issues and would only work well when both sending and 
>>> receiving email client was MailMate itself.
>>
>> I'm not sure I understand that. Sure, there is a variety of markdown 
>> that some implementations might not understand, but then it just 
>> displays a plaintext.
>
> I don't think it's that simple. Markdown comes in many variants and in 
> some cases it won't just fail to convert something, it might convert 
> it differently. Also, the plain text free nature of Markdown means 
> that there are a lot of small edge cases to consider in 
> implementations (https://spec.commonmark.org/0.31.2/).
>
> For example, most Markdown implementations do not “respect” 
> hard-wrapping lines. This does not work well for emails and therefore 
> MailMate handles it differently. Some other email client developer 
> might make a different decision. The behavior might even differ 
> between different versions of MailMate (due to changes in its Markdown 
> utility).

In these cases, where the Markdown is very variant specific, 
text/markdown (RFC 7763) is probably the right thing to do instead of 
text/plain markup=markdown. I understand that would open an entirely new 
can of worms.

> The use of “markup=markdown” by MailMate is in fact quite naive.
>
>> The simple stuff like bold, italic, etc., everyone can do pretty 
>> easily.
>
> That's a good point. There is certainly a somewhat robust subset of 
> Markdown features which could be safe to handle. Perhaps that subset 
> should be the recommended interpretation of "markup=markdown". That 
> said, the same subset would likely be quite safe for interpretation of 
> any plain text message.

Would you like to co-author an RFC? :-)

>>> For now, you only have the option of disabling the use of Markdown. 
>>> This should prevent the generation of HTML if it's not needed for 
>>> other reasons (like embedding replied HTML).
>>
>> Bummer.
>
> Well, it's not like I won't be willing to re-introduce it in some 
> form.

Love that!

>>> You are welcome to describe your use case(s).
>>
>> I subscribe to a bunch of mailing lists (primarily IETF) with a bunch 
>> of old curmudgeonly people who use old curmudgeonly clients and I 
>> would like them not to get all of the extra crud, but still allow 
>> people who can change \*italic\* to *italic* to do so.
>
> My guess is that very few (if any) of those email clients look for the 
> `markup=markdown` parameter. If they do support converting to, e.g., 
> italic for display then I would guess that they do it whether or not 
> the parameter exists.

Did I mention writing an RFC? :-)

>> (And of course there is the obsessive part of me says that you should 
>> generate the absolute minimum that you can, and sending HTML when all 
>> I've got is one italicized word is not minimum. But I assume that's 
>> why you put the option in there in the first place. I notice that you 
>> don't put in "format=flowed" if there are no wrapped lines, nor put 
>> in a "charset" when there are no non-US-ASCII characters. I just want 
>> the same thing for HTML; if you don't need it, don't include it.)
>
> Maybe the option you really need is for MailMate to only generate HTML 
> if you use “non-trivial” Markdown.

That would be fine!

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20240702/1c104796/attachment.htm>