rendering and generating text/markdown parts

[Dylan Baker]

Quoting Daniel Kahn Gillmor (2017-08-11 16:05:56)
> 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.

Someone on LWN noted that "x-" has gone out of style (officially with an RFC and
everything), so I think "text/commonmark", to distinguish it from other flavors
of 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

cmark does have a mode to disable a bunch of "dangerous" stuff, like javascript
and css, and some other things. I think it would be better if there was native
support to avoid the multipart pipeline.

For alot, there is a python library for common mark I haven't looked at too
closely, but it's ported from JavaScript, and libraries that are ports from
other languages usually feel clunky. I'm hoping to be pleasantly surprised,
otherwise I may look into writing python bindings for the C library.

For emacs, it would probably mean writing a parser in elisp.

Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20170811/44d627cb/attachment.sig>