475712 - paste unwrapped/preformatted to plain-text mail

Status: NEW

(MailNews Core :: Composition, enhancement)

Description

[tim]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5
Build Identifier: version 2.0.0.19 (20090105)

when pasting text to a plain-text message, this text is wrapped similarly to normally written text.

when pasting patches to plain-text emails, these patches will be wrapped as well, so they cannot be applied any more. it would be nice to be able to do a `paste unwrapped' or `paste preformatted', so that patches or other preformatted data are rendered correctly.

Reproducible: Always

Comment 1

[rsx11m]

I'm adding a link to the MZ forum thread where we discussed this topic today.
In general, a possible solution would be to treat the pasted preformatted text like a quotation (without leading '>', this would avoid wrapping when pasted), but also to remove any trailing spaces so that they won't be interpreted as soft line breaks in flowed-format composition.

Comment 2

[tim]

thanks ... btw, evolution provides a nice implementation of handling preformatted sections ...

Comment 3

[tim]

claws-mail provides `special paste': `as quotation', `wrapped' and `unwrapped'

Comment 4

[tim]

btw, inline forwarding of emails, the forwarded emails also get wrapped ... would be nice, if the forwarded emails wouldn't be wrapped.

Comment 5

[rsx11m]

I didn't some testing on current trunk nightly, using "banner bug-475712" as a test output to get a >72 character preformatted input:

Pasted into plain-text composition; it is wrapped in the composition window and the outgoing message, reconnected in a format=flowed capable e-mail client. Trailing spaces are correctly removed

Pasted as quotation in plain text; neither wrapped in the composition window nor the outgoing message. This currently works for display with f=f enabled, but likely only because per bug 456053 trailing spaces are removed too eagerly and therefore cause no soft line break ambiguity.

Pasted as quotation in plain text, then removed leading '>' characters; not wrapped in the composition window but then in the outgoing message as if no quotation was present, displays distorted.

Pasted normally into HTML composition, then changed to "Fixed" font; looks fine in composition and HTML display, plain-text MIME part is wrapped.

Thus, paste as quotation without removing leading '>' is currently the only way to retain the original unwrapped format in the sent message and to ensure that an e-mail client not processing f=f displays it correctly (unless wrapping and f=f are switched off completely). With f=f set, a fix for bug 456053 may cause issues here if trailing spaces are retained again in quotes and interpreted as soft line breaks.

Note that there is also bug 208128 on the opposite problem, where pasting flowed text does not result in line breaks, in this case they would be desired. Thus, a possible solution here would be to either allow a manual selection based on user knowledge, or to provide some mechanism to distinguished flowed versus preformatted text while pasting (with a sanity check similar to that proposed in bug 387687). Forwarding inline is a different issue as the context is lost, so that could only be based on something like the line length.

Confirming as a usability issue, no duplicate found [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090128 SeaMonkey/2.0a3pre].

Comment 6

[rsx11m]

Followup to comment #5:
> I didn't some testing on current trunk nightly,
/sigh/ - of course, I *did* some testing...

Comment 7

[Magnus Melin [:mkmelin]]

xref bug 204478

Comment 9

[Stanimir Stamenkov]

Currently this is possible by using a HTML composition, marking the corresponding section as "Preformat" then sending in plain text.  However using HTML composition for plain text is inconvenient for number of reasons - the one which affects me most is the "unpredictable" conversion of block/paragraph vertical gaps/margins.  The gaps/margins visible in the HTML composition are often stripped or added to the the plain text result.

"Paste Preformatted" is needed for more than patches.  I think the extra space stuffing is permissible when sending patches using format=flowed.  If one needs to ensure everybody will get the inlined patch o.k. one could use the "Toggle Word Wrap" extension:

https://addons.mozilla.org/en-US/thunderbird/addon/2351/

Using it one could disable the automatic wrapping, wrap the normal text manually (using the Edit -> Rewrap) and leave the patch preformatted.  In this mode the latest version of the extension will suppress sending in format=flowed.

Of course one could make it smarter and automatically disable sending format=flowed when there are preformatted lines which begin with a space, thus leaving the need of manual rewrapping of the normal text out.

Comment 11

[Josh Triplett]

(In reply to comment #9)
> Of course one could make it smarter and automatically disable sending
> format=flowed when there are preformatted lines which begin with a space, thus
> leaving the need of manual rewrapping of the normal text out.

That seems like a great idea.

I can see one scenario where doing so should always prove acceptable.  If a mail contains no lines that need wrapping (lines longer than the wrap limit and not marked as preformatted), then sending without format=flowed should work perfectly.

This would work similarly to the heuristic Thunderbird currently uses to send HTML-composed mails in plaintext if they have no formatting.  This heuristic would send plaintext mails in format=fixed if they have no long lines that would benefit from format=flowed.

Does such a heuristic seem acceptable?

Comment 12

[Nikos Chantziaras]

Sending code snippets in TB is realling working OK currently. I hope to see this implemented.

Comment 13

[Devin Bayer]

This would be nice to have. I see that TB doesn't wrap quoted text, which is nice. But when I want to send an inline patch, I would like to have that section unquoted. Just a "paste unwrapped" would be ideal.

I already turn format=flowed off since it seems mostly useless: https://fastmail.blog/2016/12/17/format-flowed/