From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Dylan Baker <dylan@pnwbakers.com>,
Notmuch Mail <notmuch@notmuchmail.org>
Cc: Steve Kemp <steve@steve.org.uk>
Subject: Re: rendering and generating text/markdown parts
Date: Fri, 11 Aug 2017 19:05:56 -0400 [thread overview]
Message-ID: <87y3qpn1rf.fsf@fifthhorseman.net> (raw)
In-Reply-To: <150248896497.16839.12866596405332768085@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-08-11 23:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-11 4:41 rendering and generating text/markdown parts Daniel Kahn Gillmor
2017-08-11 22:02 ` Dylan Baker
2017-08-11 23:05 ` Daniel Kahn Gillmor [this message]
2017-08-11 23:36 ` Dylan Baker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y3qpn1rf.fsf@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=dylan@pnwbakers.com \
--cc=notmuch@notmuchmail.org \
--cc=steve@steve.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).