Re: rendering and generating text/markdown parts

[Dylan Baker <dylan@pnwbakers.com>]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAlmOP4sACgkQCJ4WlhQG
iO8irQgAgRxsygL6v7cE7/Lb82GoQRcgGypmV7hm/Z7ZxLgwE0L4pdamELSuLfYk
yX1HHh4QxvOlS/gpD6D6C8G2fjDsu/pKhyOxhGTqjBm9AgLpysQltHba4Ee41DKt
9yTihCQV7ESFR9rgP+LCtCdWs6wr0DETB6DCaQtJo2vthfWGbo9IKpltdRB/1BBT
NSn509jQ5+p76/jtmhCGm+AsHrRls7z4Fxc1/z/fYRE/7WvhWiwM827C/I+5EXOR
m6EUi0wRlDJM57ZndRdYYZ9TUPAeDbXOjhUpe3/UyPsMQykwepKItvIlg5Kmzr/k
CuAdeEw8SAVNRriWE7IRdgR86SAP/g==
=MfB9
-----END PGP SIGNATURE-----