Email interface: suggested improvements


(Ron Bean) #1

I’m a member of an organization that’s starting to use Discourse, and they’re pushing to move everyone off the existing mailing list. In theory Discourse can be used like a mailing list, but I’d like to suggest a couple of improvements. The email interface is important, because email programs are highly optimized for dealing with multiple mailing lists (as opposed to having to deal with multiple web forums, each running different software).

I’m talking here about the Text/Plain MIME part of the email, not the HTML part. Note that some “power users” use email programs that don’t generate an HTML part at all-- these programs are still in use because they have advanced features that the HTML-based programs don’t seem to be interested in adding.

When Discourse mails me a message that includes quoted text, it’s marked by tags that look like this:

[quote tag goes here]
Quoted text goes here
wrapped text on multiple lines-- some email programs handle this more
gracefully than others
[close-quote tag goes here]

I can see why you want the tags in there, but it would help a lot if you could format the lines to 75 characters or so and prefix each line with “>”. This makes it obvious at a glance what’s quoted text and what isn’t (otherwise it all looks pretty much the same). If the quoted text is re-quoted in the reply, you’ll still have the tags.

When I sent a test reply, formatted as I normally do for a mailing list, I got this error message:

We couldn’t find any content in your email. Make sure your reply is at the top
of the email – we can’t process inline replies.

If you’re getting this and you did include content, try again with HTML
content included in your email (not just plain text only).

I’m not sure why you need to “find content” in an email post, it should be just fine to post it as-is. But inline replies are the clearest way to respond to multiple points in one message, and they’re not that hard to parse. You can safely assume that a bunch of lines each beginning with “>” (or occasionally “|”) are quoted text, and anything that’s not quoted is new text. You also know which message the user was replying to (this is the purpose of the “In-Reply-To:” email header, but Discourse also puts its own coding in the header).

Sometimes quoted text will be one very long line beginning with “>” (no line wrap). You may also see multiple levels of quoting, with or without spaces between the ">"s. BTW there are text editors that can accurately reflow paragraphs with multiple levels of quoting intact, so I don’t think it’s difficult. But do be careful, because some text wasn’t meant to be reflowed (eg, program listings).

In rare cases, you may find a line beginning with “>From”, surrounded by other non-quoted lines. This isn’t quoted text, it was a work-around for an old bug, but I still see it occasionally. (If the surrounding lines are quoted text, then this line is also quoted text.)


(Sam Saffron) #2

I think it is a bit of a user preference here.

  • Some users, just want to hit “Reply” and know that the whole “chain” is not going to be duplicated in the email.

  • Some users, like to carefully craft replies and are careful not to include any duplicate text.

I am open to adding a user preference for this, or perhaps some heuristic that detects that this happened.

Regarding the quoting problem:

The syntax we currently use is

[quote="rbean, post:1, topic:32140"]
Quoted text goes here
[/quote]

I think it would probably be more elegant if moved globally to a syntax like this

> Quoted text goes here
{quote=rbean,1,32140}

But a change like his is very hard and complex.

You can see some of the discussion here: Consistent attribute syntax - Extensions - CommonMark Discussion

When you are crafting replies in your email client you can use the standard quoting, but will lose metadata.

Regarding line lengths: we have a site setting that enables “traditional” markdown. You can see some of the discussion here:


(Ron Bean) #3

There should be an option in the user’s email program to include or not include the previous email in the reply. But if the user ignores it and includes it at the bottom, it should be fairly obvious: non-quoted text followed by quoted text in one large block, not broken up, which happens to match what Discourse sent out (you already know what they’re replying to).

I would guess that the kind of user (like me) who pays attention to readability when replying would not mind setting an option to that effect (ie, “don’t screw up my text” vs “remove the cruft from my emails”).

[FWIW, my current work-around is to read via email but reply via the web interface. It should be possible to do better, though.]