I think this is probably very difficult to get right; see also some discussion in T185.

That said, we could give it a shot and see how bad it is.

One thing we could also do is make the entire original mail body accessible instead of discarding it. GitHub does this by hiding it in a small "..." in the footer -- then even if we get things wrong, the text is less convenient to get at instead of lost.

I think getting to an 95% solution shouldn't be too hard (mainly effort, which is why I haven't done it myself yet), and just including most of the email for the 5% where we don't get it right seems better than not having the comments in the phab thread at all. Then I'd guess it's 1. wait for bug filed, 2. add regexp, 3. redo from start.

If we always want to make the whole email available, the question is still what to show in phab when somebody is not top-posting, so I'd say those are related but not completely the same issue.

I was going to post a new ticket. I am not sure, if this is the right ticket...

This was an e-mail reply.

Again, another top posting test.

Test:
> On Fri, Aug 07, 2015 at 04:53:33PM +0000, Patrick Schleizer wrote:
> line one
> line two
> line three

Some inline reply.

> Some more.

Another inline reply.

> Even more.
> End

This comment was the result:
https://phabricator.whonix.org/T33#6331

The inline replies got lost.

Is this what this ticket is about?

Can this feature be optionally disabled?

In T5181#61190, @epriestley wrote:

One thing we could also do is make the entire original mail body accessible instead of discarding it. GitHub does this by hiding it in a small "..." in the footer -- then even if we get things wrong, the text is less convenient to get at instead of lost.

Sounds good.

@adrelanos: yes, that's what this ticket is about.

(Just creating an example via email for my next reply.)

Well, there's an unrelated bug.

The caret dropdown menu should have a "View Email Body" for email replies with the raw email, although I think this isn't really the raw email but the body-stripped email. We could make that the actually-raw body, I suppose.

We can make some effort here but I generally worry it will be very time consuming and never produce very good results unless we completely give up and just blockquote replies and don't try to mark them up, but that's also gross. T7478 is one example of popular clients not preserving or transmitting text in the way users expect them to. This isn't adjacent to any other work.

In particular, I think we're going to hit cases like this:

> quack quack quack
bark bark bark

...and have no idea if "bark bark bark" is the first line getting wrapped or an inline reply, and every time we get it wrong someone will file a task complaining that we're the worst software in existence.

In T5181#136123, @epriestley wrote:

In particular, I think we're going to hit cases like this:

> quack quack quack
bark bark bark

...and have no idea if "bark bark bark" is the first line getting wrapped or an inline reply, and every time we get it wrong someone will file a task complaining that we're the worst software in existence.

It would be better to reject incoming emails with inline comments from such email clients (such as gmail), as opposed to get it wrong.

One approach to workaround that sticky situation is to require that incoming mail with inline comments and an unclear encoding have a blank line after the quoted text. I think it is reasonable for email users to help the server out a little in that situation.

In T5181#170236, @jayvdb wrote:

In T5181#136123, @epriestley wrote:

In particular, I think we're going to hit cases like this:

> quack quack quack
bark bark bark

...and have no idea if "bark bark bark" is the first line getting wrapped or an inline reply, and every time we get it wrong someone will file a task complaining that we're the worst software in existence.

It would be better to reject incoming emails with inline comments from such email clients (such as gmail), as opposed to get it wrong.

Can you expand on what gmail for example does wrong here?

See T5181#136121 above.

Jay: ok then, while I'll not argue about whether breaking is correct or not, gmail does break citations correctly.
That is, if I open an email and write (break before "unrelated newline"):

Myself wrote:

test something something somethings test something something somethings test something something somethings test something something somethings test something something somethings

unrelated newline

I get:
Myself wrote:

test something something somethings test something something somethings
test something something somethings test something something somethings
test something something somethings

unrelated newline

Which seems totally fine to parse (?)