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
_______________________________________________
mailmate mailing list
Unsubscribe: https://lists.freron.com/listinfo/mailmate