Disable indent code block for emails

feature
1

Many posts in my forums are created via email. They do not contain code.

Would appreciate a setting to turn off the four-character code-block feature of Markdown when the post originated from an email.

That is to prevent many email paragraphs being turned into code blocks due to paragraph indents.

10 Likes
2

I wholeheartedly second this request with an extra :heart:.

1 Like
3

hmmm … I thought we had incoming email prefer html and that is default on?

So you are saying you have people composing stuff in plain text mode and indenting?

Can you reply to this post via email with an example problem?

3 Likes
4

No, it’s the email client that’s adding these whitespaces (in the HTML version).

The actual bug is that our html-to-markdown library isn’t interpreting whitespace as well as the browser does.

It’s been on my TODO list since the inception of incoming email support.

8 Likes
5

We do have emails sent in text-only. Usually sent by people with older email systems, but that is not at all rare.

What is rare is email containing code fragments.

6

+1
I fully second this!

12

Ok, I’m old. I’m also a publisher of books (on paper and electronic). Books indent new paragraphs. In letters or emails that use this convention, a tab is used. I’ve looked through the posts on this topic and haven’t found if there is a way to allow tabs as a default. (Or at least allow 4 or 5 spaces to function as an indent.)
Is this possible without complicated programmin or plugins?

1 Like
13

Yeah we have meant to work on this issue for quite a while now, thanks for the reminder, there is no setting now but we plan to sort this out.

5 Likes
15

Thanks for the prompt and encouraging reply. I’ve been very impressed by Discourse, and by the helpfulness of the community.

1 Like
16

This will help a GREAT deal in getting much less messy emails!

17

I just submitted a pull request to introduce a new site setting strip incoming email lines . I did not want to completely disable code blocks when this setting is enabled, so code blocks will still be accepted between [code]…[/code] and ```…```, but all the other lines will be stripped (leading and trailing whitespaces will be removed).

For example, the following email:

MIME-Version: 1.0
Date: Tue, 01 Jan 2019 00:00:00 +0300
Subject: An email with whitespaces
From: Foo <foo@discourse.org>
To: bar@discourse.org
Content-Type: text/plain; charset="UTF-8"

Hello

    This is a line that will be stripped
    This is another line that will be stripped

This is a line that will not be touched.
This is another line that will not be touched.

[code]
  1.upto(10).each do |i|
    puts i
  end
[/code]

    This is going to be stripped too.

Bye!

will produce the following reply:

Hello

This is a line that will be stripped
This is another line that will be stripped

This is a line that will not be touched.
This is another line that will not be touched.

  1.upto(10).each do |i|
    puts i
  end

This is going to be stripped too.

Bye!

disabling this setting will create the following reply:

Hello

This is a line that will be stripped
This is another line that will be stripped

This is a line that will not be touched.
This is another line that will not be touched.

  1.upto(10).each do |i|
    puts i
  end
This is going to be stripped too.

Bye!

8 Likes
19

Excellent! Thanks, Dan. This will clean up a large number of our incoming emails. :ok_hand:

3 Likes
20

Cool so the upshot of this setting is that traditional space indented commonmark code blocks become impossible, right? No other side effects? That seems like a reasonable tradeoff for sites that have the “random space indenting problem” :wink:

4 Likes
21

Unfortunately, no. Stripping every line also results in losing levels for nested lists.

* parent
  * child 1
  * child 2

becomes

* parent
* child 1
* child 2
5 Likes
22

A better way is probably to trap the code block recognition from the MarkDown engine and change the block type to normal text.

2 Likes
23

This is kind of an edge case behind a flag that has to be opted in. It’s not worth a ton of engineering, a “good enough” solution is fine.

2 Likes
24

Agree. Who uses multi-layer bullets anyway? Not many I predict.

1 Like
25

Of course, that would be ideal, but it is a lot more effort than you would think.

Our “post cooking” (converting raw text to HTML) pipeline is quite complex and in the end it gets to MarkdownIt, which does not offer something such as a reverse mapping.

7 Likes
26

Or… Only strip leading white space if the first letter of the line is not an obvious bullet mark like * or -.

That still won’t solve the problem for multi-layer numbered lists but those should be very rare…

7 Likes
27

That is an excellent idea!

https://github.com/discourse/discourse/commit/35a866fe229ffe6a22b947a671c82c1bcc7dec51

7 Likes