To reproduce, configure your mail account to compose in plain text mode (uncheck compose in HTML). This test case assumes you have line wrap configured to 72 chars (the default). - compose a new mail message - click into body - copy and paste the following text (72 chars) 123456789012345678901234567890123456789012345678901234567890123456789012 - place cursor at the end of the line - hit space multiple times - note that the caret does not move. It appears the typing has no effect. - type any char, now the caret moves to the next line - now hit backspace multiple times. When you hit backspace first, the last character gets removed. Continue to hit backspace, you'll notice that you have to hit backspace as often as you had hit space before, without the caret moving, before the displayed numbers get deleted. This is broken and not what the user expects. Another example that shows how it is broken: - copy the following line to the plaintext mail compose window (70 chars) 1234567890123456789012345678901234567890123456789012345678901234567890 - place caret at end of line - hit space 2 times. you'll see the caret moving - hit space again. This causes the blanks you entered before to disappear! The caret moves 2 positions to the left. Now hit backspace, and the caret jumps to the end of the line. Expected behaviour in the plaintext editing mode: - Each entered space must be shown unconditionally as a separate independent character, and the caret must move for each entered space. - In the wrapping example, when additional spaces are entered at the end-of-line position, the caret must move to the next line and additional spaces typed must show up on the next line.

is this a duplicate bug?

This is intentional behavior. The alternative is that spaces wrap to the next line. This is how it used to be for plaintext widgets (textareas, etc) and we got bug reports on it. I don't remember the bug number where this was fixed - it was fixed in layout, not in editor, I think. If we didn't do this, you would get a leading space on the next line if the previous line's last character was right at the wrap length. And in the case of hitting 2 spaces after the end of a sentence, you could end up with both spaces leading the next line. Nobody liked that. It was decided that "invisible" spaces at the ends of lines was better. I agree it is confusing.

I'm going to close this as invalid since other mail clients also behave this same way.

Eudora and Mail.app don't do proper plaintext wrapping; ignore them. MT-NewsWatcher and BBEdit do, and show multiple blanks at the end of lines.

I should add that to achieve this, you have to treat trailing whitespace on a line as special, and allow it to go past the wrap column. If you still don't want to fix this, mark it WONTFIX, rather than INVALID.

An interesting idea. I didn't realize BBEdit did this. Of course, it doesn't help text widgets, since their wrap width is also the width of the widget. To show those spaces you would have to put up a scroll bar, which is kinda freaky for a widget that is supposed to wrap to it's width. But we could do it for plaintext mail.

topembed+

This is really a layout issue.

-> Kin

editorbase+

*** This bug has been marked as a duplicate of 87314 ***