Remove hard breaks in plain-text emails

[omentic]

Checklist

• [X] I have used the search function to see if someone else has already submitted the same feature request.
• [X] I will describe the problem with as much detail as possible.
• [X] This issue only contains a request for one single feature, not multiple (related) features.

App version

latest

Problem you are trying to solve

For reasons I do not understand, breaking lines at 72 characters in plain text emails is a historical standard, instead of delegating such line wrapping to email clients. As K-9 is a mobile client the screen is of course smaller - and so this line wrapping acts contrary to its intended purpose, making emails much harder to read. I frequently receive emails that look like the following:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
 do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim
 ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut
 aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in
 voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
 sint
occaecat cupidatat non proident, sunt in culpa qui officia
 deserunt
mollit anim id est laborum.

Suggested solution

It would be nice if K-9 would take a "Markdown approach" to line breaks in plain-text emails and wrap them nicely.

Screenshots / Drawings / Technical details

No response

[shader]

I am also interested in this feature, since I use K9 with an account where I frequently send and receive plaintext emails.

However, I think it would be better to support the standard "format=flowed" solution, which is backwards compatible with many plaintext clients. There is a formal specification at https://datatracker.ietf.org/doc/html/rfc3676

So there are two or three components of this feature:

1. K9 should display format=flowed messages correctly according to the specification
2. K9 should be able to format and send plaintext emails using format=flowed. This basically means automatically wrapping with soft breaks (SP CR LF instead of CR LF), and adding the appropriate header flag.
3. To support cases where the message is not in format=flowed, we could have multiple view modes: default, re-wrap, and overflow-scroll. It would need to be easy to change between them on a per-email basis though.

[cketti]

1. K9 should display format=flowed messages correctly according to the specification

K-9 Mail already supports displaying messages using format=flowed.

2. K9 should be able to format and send plaintext emails using format=flowed. This basically means automatically wrapping with soft breaks (SP CR LF instead of CR LF), and adding the appropriate header flag.

K-9 Mail always uses Content-Transfer-Encoding: quoted-printable so the decoded text only contains the line breaks manually inserted by the person composing the message. The effect is the same as using format=flowed. See #2302.

3. To support cases where the message is not in format=flowed, we could have multiple view modes: default, re-wrap, and overflow-scroll. It would need to be easy to change between them on a per-email basis though.

I understood this feature request to be only about displaying (historical/broken) messages. But I'm not sure adding a bunch of manual display modes is the best option. We can probably detect such messages automatically and rewrap the text with an option for the user to show the original formatting.

[shader]

K-9 Mail already supports displaying messages using format=flowed.

Yes, after some testing I found that K-9 does indeed render format=flowed messages correctly. I had assumed it wasn't because of some messages that must have been quoted-printable, and the entry on https://useplaintext.email/ that says it doesn't meet the "Wraps text or format=flowed" criteria, but I guess that was for the composition side of things.

K-9 Mail always uses Content-Transfer-Encoding: quoted-printable so the decoded text only contains the line breaks manually inserted by the person composing the message. The effect is the same as using format=flowed. See #2302.

There is no support in quoted-printable for soft line breaks, so either it is hard-breaking in a way that will look poor on some screen sizes, or leaving long lines contrary to proper plaintext email style. But perhaps supporting composition of emails in format=flowed style should be a separate issue, since this is about display.

I understood this feature request to be only about displaying (historical/broken) messages. But I'm not sure adding a bunch of manual display modes is the best option. We can probably detect such messages automatically and rewrap the text with an option for the user to show the original formatting.

I think this could work, and I just found FairMail does that - by default it reformats the message, but has a toggle for showing the original content. The only reason I suggested the third option (original formatting with overflow=scroll) is to handle those cases where original formatting is desired but without the awkward line wraps. That would probably be a separate feature that would go deeper in the settings to configure what "original format" means.

So yes, I think this feature could be simplified to "auto-reformat + toggle to view original format"; which case is the default (original or reformat) should probably be a setting though.

[benbucksch]

leaving long lines contrary to proper plaintext email

Yes, the very long lines, where essentially a paragraph is very long line, and leaving it to the recipient to wrap them, doesn't always work with all receiving clients, esp. when replying and quoting, some clients then put the whole paragraph on a single line. (Sorry for not giving specific examples of email clients, it's mostly anecdotal first-hand experience.)

[cketti]

There is no support in quoted-printable for soft line breaks, so either it is hard-breaking in a way that will look poor on some screen sizes, or leaving long lines contrary to proper plaintext email style.

When decoding format=flowed, you also end up with long lines. If an email client can deal with that, it could also wrap regular long lines on display. But if you insist that this is not "proper plaintext email style", you probably don't want to use K-9 Mail anyway. Because wrapping long lines when displaying non-format=flowed text/plain parts is exactly what K-9 Mail is doing.

Yes, the very long lines, where essentially a paragraph is very long line, and leaving it to the recipient to wrap them, doesn't always work with all receiving clients, esp. when replying and quoting, some clients then put the whole paragraph on a single line. (Sorry for not giving specific examples of email clients, it's mostly anecdotal first-hand experience.)

That's a reason to fix those email clients, not to revert to text processing like it's 1960.

None of you expected GitHub to add "soft line breaks" to your text, so the comments are displayed somewhat okay in some weird browser. Why should it be different when writing emails?

[benbucksch]

The advantage of format=flowed is that it helps the entire ecosystem.

• If you send in format=flowed, and the receiver does not support format=flowed, they will display with a reasonable width (but not flow), but when the non-supporting email client then replies and quotes, the quote will be reasonable. The line length of the quoted part will not exceed 80 characters - even though the email client quoting doesn't support format=flowed.
• If you send in format=flowed, and the receiver also supports format=flowed, the emails are going to be perfect, both for reading and quoting.
• If you send in quoted-printable, and the receiving client can decode it, but is not careful in the view or - more commonly - while quoting, the quote will have very long lines. The resulting quotes are then hard to display correctly and readable, in conforming clients. Unfortunately, there are a lot of email clients which to not pay sufficient attention for quoting line length in plaintext emails, so this problem is very common.

After all, your user is exchanging messages with somebody else, and needs to read the messages and quotes that the other person sent, and your user has no control over the email app of his communication partners. So, preparing the email, so that every email app can nicely display and quote it, helps everybody: Your user, the receipients, and everybody else reading the thread.

[MaxGyver83]

3. To support cases where the message is not in format=flowed, we could have multiple view modes: default, re-wrap, and overflow-scroll. It would need to be easy to change between them on a per-email basis though.

I understood this feature request to be only about displaying (historical/broken) messages. But I'm not sure adding a bunch of manual display modes is the best option. We can probably detect such messages automatically and rewrap the text with an option for the user to show the original formatting.

This would be really cool! I often receive mails like that (usually in plaintext-only mailing lists).

I'm aware that FairMail supports this. I have tried it some time ago. But I like the overall experience of K-9 Mail much better and won't switch because of a single feature.

[belkka]

@cketti

None of you expected GitHub to add "soft line breaks" to your text

Actually, we all kind of do (including you). This is a very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very long line and I do expect GitHub to add "soft line breaks" when displaying this text. I assume GitHub accomplish this by relying on appropriate HTML tags, to indicate that this text should be soft-wrapped (according to HTML semantics).

On the other side, I want this to be pre-formatted as plain text:

Should I add a very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very
long line, it shall be rendered without soft-wraps (but rather with horizontal scroll bar).

GitHub achieves this using a <pre> HTML tag to tell my browser about "plain text pre-formatted" chunks:

The pre element represents a block of preformatted text, in which structure is represented by typographic conventions rather than by elements.

GitHub doesn't put the whole comment into <pre> tag, but only some chunks of it (which I specify using GitHub's comment editor or Markdown).

As mentioned by @shader, this discussion is indeed more relevant to separate issue, so I'll add more clarification in https://github.com/thunderbird/thunderbird-android/issues/2302