On Friday, 5 June 2015 at 09:16:30 UTC, sigod wrote:
How about markdown support? It can have completely client-side implementation.

I have thought for a long time about this.

It's tricky.

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 extensions.

4. Markdown's formatting for code (leading whitespace) is rather cumbersome, and difficult to use without either visual JavaScript 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 lines).

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 can't display.

To sum it up, it's a can of worms, and I'm fairly sure we're doing quite well without it.

Reply via email to