rendering and generating text/markdown parts

[Daniel Kahn Gillmor]

On Fri 2017-08-11 15:02:44 -0700, Dylan Baker wrote:

> Natively no. I have a fairly minor patch to alot that would make it work if the
> type was text/markdown instead of text/plain.

huh, i tried to set Content-Type: text/markdown in emacs mml-mode by
just fiddling with the header but mml apparently believed that it knew
better than i did what Content-Type header to send and sent out
text/plain anyway :/

> I have another patch that makes this render correctly as markdown, but it breaks
> lots of other text/plain emails that use characters in a way that they look like
> markdown to cmark, but aren't actually markdown.

yeah, i agree we should *not* try to apply these filters to anything not
marked explicitly as text/markdown.

> I think if we're going to have a message format we should use text/markdown or
> text/commonmark, or text/x-(markdown|commonmark) rather than text/plain as the
> format. While it's safe to read markdown as plain text (it was originally used
> that way anyway), it's not safe to assume that all text is valid markdown.

Absolutely agreed.

> elinks with "-dump-color-mode 1" did a pretty good job of formatting the html that
> came out of cmark. I've attached that if anyone wants to see it.

Interesting, it does look plausible, though i confess i don't like the
idea of needing a two-stage pipeline. seems like a lot of attack surface
and moving parts :/

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20170811/6432713f/attachment.sig>