I disagree, because it's (far) easier to soft-wrap QP long lines than it is to unwrap hard-wrapped short lines. Hard-wrapping essentially causes a loss of information, by not distinguishing between user-inserted and program-inserted newlines.

Any client program can wrap as appropriate (which is not always to 80 chars, but 80 chars would work as well as anything) with QP; the same is not true of hard-wrapped as gmail does it.

Once you insert all the line breaks, the email clients can not reliably reconstruct the original paragraphs anymore.

Yes, the point of the convention is to make text fit on the 80 char terminal. Nowadays clients use extremely different viewer widths, thus it's an outdated recommendation, that should not be followed anymore.

> What should be done, I believe, is that e-mail _clients_ should detect the 78-character convention and rejoin the lines into paragraphs if they think it would be best.

That’s what format=flowed allows. The sending client line-wraps long lines at 78-or-so characters and then indicates having done so by appending an extra space at the end of such lines. This way, clients can either

  (a) leave everything as-is, the trailing spaces won’t hurt or

  (b) rejoin the lines into one long paragraph.

I would probably prefer the latter behaviour on a phone or screen with less than 80 characters, whereas on the desktop, I’d rather not be presented with lines running over the entire width of the screen.

But really, this is pretty standard in mail clients…

Edit: added quotation mark, sorry.

The point of typing a message in a webmail UI and sending it is to deliver the exact message you entered to the recipient. Adding hard line breaks, effectively altering the original message, is not useful.

Making text fit on a 80-character fixed-width screen is not something the email sender should do; the recipient’s email client should do it based on their preferences.