rendering and generating text/markdown parts

classic Classic list List threaded Threaded
4 messages Options
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

rendering and generating text/markdown parts

Using `Content-Type: text/markdown`
-----------------------------------

[Over on LWN, some discussion came up about rendering and generating
text/markdown variants of e-mails](https://lwn.net/Articles/730277/)

This is similar to (but maybe simpler than) [a proposal that was
discussed on the alot bug tracker earlier this
year](https://github.com/pazz/alot/issues/1051).

I thought i'd drop this mail as a marker for the start of a longer
discussion if anyone wants to try to take it further.

Next Steps
----------

I think this mail is (hopefully) actually composed correctly as
text/markdown.

Does anyone's MUA render it properly?  Anyone want to post screenshots
or other renderings?

Anyone have suggestions about message composition in markdown?

           --dkg
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Dylan Baker Dylan Baker
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering and generating text/markdown parts

One of the alot devs here,

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.

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.

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.

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.

Dylan

Quoting Daniel Kahn Gillmor (2017-08-10 21:41:52)

> Using `Content-Type: text/markdown`
> -----------------------------------
>
> [Over on LWN, some discussion came up about rendering and generating
> text/markdown variants of e-mails](https://lwn.net/Articles/730277/)
>
> This is similar to (but maybe simpler than) [a proposal that was
> discussed on the alot bug tracker earlier this
> year](https://github.com/pazz/alot/issues/1051).
>
> I thought i'd drop this mail as a marker for the start of a longer
> discussion if anyone wants to try to take it further.
>
> Next Steps
> ----------
>
> I think this mail is (hopefully) actually composed correctly as
> text/markdown.
>
> Does anyone's MUA render it properly?  Anyone want to post screenshots
> or other renderings?
>
> Anyone have suggestions about message composition in markdown?
>
>            --dkg
>

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

elinks-out.txt (2K) Download Attachment
signature.asc (499 bytes) Download Attachment
Daniel Kahn Gillmor Daniel Kahn Gillmor
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering and generating text/markdown parts

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

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

signature.asc (847 bytes) Download Attachment
Dylan Baker Dylan Baker
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering and generating text/markdown parts

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

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch

signature.asc (499 bytes) Download Attachment
Loading...