On Friday, 5 June 2015 at 09:16:30 UTC, sigod wrote:
How about markdown support? It can have completely client-side
I have thought for a long time about this.
There are multiple concerns:
1. People receiving messages through NNTP/mailing lists will not
see the formatted Markdown. Although Markdown's goal is to be
readable in its plain text source code, it still allows many
situations in which the source is misleading or difficult to
understand. For example, special characters need to be escaped by
a backslash, which can create confusion in the presence of other
special characters. (Are they part of the D syntax the user is
describing, or something else?) Some syntax such as tables or
images can also be not very readable in source form.
2. How should we render messages sent by NNTP/mailing-list users?
Do we just assume that they're sending Markdown and render it as
such? This can cause the messages to appear broken to forum
users. Or do we only render Markdown if the post was sent from
the forum? This means that when NNTP/ML users quote forum users'
text it will be shown as plain text.
3. There is no unified standard for Markdown. The original format
is not used on major sites today - StackOverflow and GitHub
extend the format, and users will expect Markdown with those
4. Markdown's formatting for code (leading whitespace) is rather
text editors (as on SO) or Markdown extensions (as on GH).
5. You can't edit posts once sent. This means that if you
accidentally messed up the formatting (e.g. you pasted code
without padding it with whitespace or surrounding it in ```...```
blocks), you can't go back and edit it now.
You see this all the time on StackOverflow (even though it's
user-editable) and more importantly on the vibe.d forums. It's
pretty ugly, and in some cases, borderline unreadable (any
indented lines are shown drastically different from unindented
6. How do we encode that the message is in Markdown in the
message's headers? "text/plain" + a proprietary header would be
lying. "text/markdown" or something like that will likely cause
the message to not be displayed at all in some readers. Sending a
"text/html" part with rendered Markdown is an idea, but it also
invites clients to send a "text/html"-only reply, which DFeed
To sum it up, it's a can of worms, and I'm fairly sure we're
doing quite well without it.