Content-Type: text/markdown

Posted Aug 9, 2017 18:25 UTC (Wed) by dkg (subscriber, #55359)
In reply to: Active Desktop says hello by skx
Parent article: The coming WebKitGTK+ 2.4 apocalypse

i like this idea, skx. You might get a slightly larger "small number of friends" if you promoted the idea of a text/markdown alternative to other MUAs. I tend to work on the notmuch project, and i suspect the other developers there would be interested.

I imagine a number of other MUA developers could get behind this as well. How do you resolve the issue of different markdown flavors?

Content-Type: text/markdown

Posted Aug 9, 2017 18:33 UTC (Wed) by skx (subscriber, #14652) [Link] (4 responses)

Honestly? I just picked the first Lua-based markdown parser/renderer that I could find and used that.

While I know that there are significant differences in different flavours of markdown most of those are irrelevant in simple emails.

(i.e. The cases that are difficult such as nested lists, tables, etc, aren't the kind of things that users manually type too often. Mostly they use bold, italic, and if they're really keen they might write a link or two in markdown format - but the latter is often a stretch.)

I'm not even sure where to start with any proposal/standard process short of spamming a few mailing lists, but certainly "text/markdown" is what I used. I also added a flag for "forcibly treat _this_ email as markdown".

I should polish it a little and document it in my mail-client sometime soon:

https://lumail.org/

Content-Type: text/markdown

Posted Aug 9, 2017 19:54 UTC (Wed) by jani (subscriber, #74547) [Link] (3 responses)

I think you could start producing standards compliant markdown MIME messages by wrapping the messages in a multipart/alternative container, and including both text/plain and text/x-markdown (or text/markdown if you go by [1], or text/x-rst for reStructuredText for that matter) parts. Since the point of lightweight markup is that it's close to plain text, you could just use the same contents for both parts. If you include the text/plain alternative I believe most MUAs will cope just fine.

Trying to send the entire message using some obscure MIME type will not fly, at least not until you've reached critical mass. But hey, you gotta start somewhere!

For the Notmuch Emacs frontend [2], if there's an elisp renderer for text/whatever MIME type, adding a handler for it should be trivial. Also, FWIW, it already has a way to display any part using user specified MIME type, provided there's a handler for it.

[1] https://tools.ietf.org/html/rfc7763
[2] https://notmuchmail.org/notmuch-emacs/

Content-Type: text/markdown

Posted Aug 11, 2017 21:35 UTC (Fri) by derobert (subscriber, #89569) [Link] (2 responses)

FYI: x-prefixes are now generally considered to have been a mistake, or at least an idea that didn't work out. See BCP 178. Appendix B gives rationale, but in short there are better ways to generate private names, and anything that is intended to be interoperable winds up having to keep the X- name forever to avoid a flag day. So you wind up with the X- name de-facto (or actually) standardized anyway, defeating the purpose.

Content-Type: text/markdown

Posted Aug 11, 2017 22:00 UTC (Fri) by jani (subscriber, #74547) [Link]

Thanks. Makes sense.

Content-Type: text/markdown

Posted Aug 13, 2017 4:31 UTC (Sun) by roc (subscriber, #30627) [Link]

This matches what we learned about vendor prefixes in Web APIs.

Content-Type: text/markdown

Posted Aug 10, 2017 16:48 UTC (Thu) by dbaker (guest, #89236) [Link] (4 responses)

I'm one of the alot devs (https://github.com/pazz/alot, which is a frontend for notmuch) we've talked about using markdown to generate HTML messages, but I really like the idea of using markdown as an interchange format instead. It's much richer than plain text, but without the insanity that HTML brings.

I think that using CommonMark would be a good way to go, it's already spec'ed and it's what github uses, which makes it pretty ubiquitous.

If alot and notmuch-emacs both supported the same flavor of markdown and could communicate with each other that way it would be a good start.

Content-Type: text/markdown

Posted Aug 10, 2017 16:54 UTC (Thu) by skx (subscriber, #14652) [Link] (3 responses)

Sounds like a plan is coming together! I'm not sure how much coordination is required, but it might be worth moving the discussion elsewhere.

I guess I'm thinking of two-things:

* Incoming messages of text/markdown will be rendered as markdown, whether via an export to HTML and a dumping via Lynx, Links, w3m, or similar. (Depends on console vs. GUI a lot. Obviously the user should select their preference, as they might already do now to prefer text/plain to text/html, or vice-versa.)

* Outgoing messages can be sent as multi-part/mixed with both text/plain and text/markdown

There might be fiddly details to be made, but those two core things seem like they should be non-controversial. I'd agree CommonMark is probably the way to go right now, standards are good :)

Content-Type: text/markdown

Posted Aug 11, 2017 0:23 UTC (Fri) by dbaker (guest, #89236) [Link] (1 responses)

Maybe multipart/alternative instead of multipart/mixed? That would allow the sender to generate a plaintext or html alternative to the markdown for clients that don't know about text/markdown.

Content-Type: text/markdown

Posted Aug 11, 2017 4:29 UTC (Fri) by dkg (subscriber, #55359) [Link]

i agree it should be multipart/alternative, not multipart/mixed

If no one has a preference for another place to take the discussion, i recommend the notmuch mailing list since that should already be a decent place for discussing alot and notmuch-emacs.

Content-Type: text/markdown

Posted Aug 11, 2017 10:28 UTC (Fri) by felix.s (guest, #104710) [Link]

Wasn't Markdown intended to be directly human-readable? And doesn't the definition of text/* encourage implementations to fall back to direct displaying? Why bother with the multipart/* nonsense?