Users report that Discourse’s email trimming algorithm incorrectly removes lines of hyphens (used as underlines for headings in plain-text emails), mistaking them for email signature delimiters. artur demonstrates that markdown-style Setext headings (e.g., Header\n------) get trimmed, breaking content. Disabling trimming avoids the issue but causes long email threads to clutter web views artur. Falco suggests using ATX headings (# Header) instead, but ThiefMaster, from the email-sending app, notes these are plain-text emails, not markdown, and underlined headings are more visually appealing. They propose recognizing email signatures by the -- delimiter preceded by a blank line, pointing to the relevant code Falco. artur finds that mixed-character lines (e.g., -=-=-=-=) are not trimmed, suggesting using non-delimiter characters as a workaround. The issue remains unresolved, with a PR welcome but cautioning against regressions.
We encounter an issue when email contain hyphens underlining a line, which markdown recognises as a heading. This is trimmed away by the trim algo. We have to always show the trimmed content since many people use our instance by email only.
Steps to reproduce:
Basically in the Advanced Email test enter:
This is text before
Header
------
This is text after
Which in markdown would be rendered as:
This is text before
Header
This is text after
The result is that the text before the header is removed and after is elided!
Is there a way to adjust the trimming to not elide lines of hyphens that follows a line with the same number of characters? At least markdown seems to be able to deal with that.
Yes of course disabling the trimming does not elide the next
However, the problem then comes when people reply to a very very long email thread via email and then all that thread is shown the web view. That is not nice. Hence I would like to re-enable the trimming!
So you want the trim feature enable but the ----- signature removal feature? That’s tricky. Can users be told to use ATX headings instead of Setext headings?
As the lead developer of the application that creates the emails @artur talks about: Yes, we could change it (or use ^^^^ instead of ---- in the “underline”), but this is technically not markdown but simply a text/plain email that’s formatted in a “nice” way for humans. And the “underlined” headings do look a bit nicer IMHO than using markdown-style # something headings
Anyway, don’t email signatures that are delimited with -- usually have a blank line right before the -- line? So maybe that could be taken into account when parsing emails?
