Evolution plain-text email includes formatting "stuff" - should be pure plain text

Bug #288185 reported by Peter Whittaker on 2008-10-23
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evolution
Invalid
Undecided
Unassigned
gtkhtml3.14
Won't Fix
Low
gtkhtml3.14 (Ubuntu)
Wishlist
Ubuntu Desktop Bugs

Bug Description

Binary package hint: evolution

If a user sets their preferences to use/prefer plain-text email, then all new emails and all replies should be pure plain-text - no formatting boxes, no formatting choices, etc. Plain text is plain text.

Instead, when I reply to certain emails, there are formatting boxes present in the reply - those boxes with "dotted line edges". These contain the quoted reply. They shouldn't be there!!! And they make it extremely difficult edit a reply properly.

With plain text selected, there should be the "X wrote Y on D" header, the quoted reply (>... with an intelligent line length limit, e.g., 72), and any auto-inserted signature. And they should all be plain text lines.

In other words, I should be able to insert new lines and new text anywhere I want: After the header, in the middle of the quoted test, before the signature, etc.

But I cannot, because evolution appears to be trying to be helpful and is missing the mark.

This makes it somewhere between aggravatingly inconvenient and impossible to format replies as I want, in other words, to achieve proper emphasis, to rearrange text conveniently for readability, etc.

(On a possibly related note, I used to be able to use ctrl-L to go reflow quoted text and it would do the right thing - that has disappeared. Are these related directions?)

Every time I encounter this aggravation I seriously consider going to Mutt, despite its configuration complexity problems, or, worse, pine, which was quite a good MUA, despite its licensing challenges. The calendar and contacts integration is keeping me on evolution, but I'm not sure how long that will last.

This is not a wishlist item, this is a usability and accessibility issue: If a user chooses and prefers plain text, give them plain text.

(I've trolled the help and all preferences to make sure I am not missing anything, to ensure I have plain-text selected everywhere I need to, because this is extremely aggravating and is a serious - I'm not kidding! - productivity issue.)

Sebastien Bacher (seb128) wrote :

the request is an upstream wishlist and should be sent on bugzilla.gnome.org

Changed in evolution:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
Peter Whittaker (pwwnow) wrote :

This is not a "I wish it were otherwise" feature request: This is an accessibility and usability bug.

When a user makes a data format input/display choice, a choice supported by the software, they are making an accessibility choice. If the software gets it wrong, the software requires correction.

If I choose plain-text, I should get text as plain as in this form, as in vi, as on a piece of paper. No bells-and-whistles, no attempts to be helpful, no attempts to second-guess what I *really* meant. Either of the latter is simply paternalistic and contrary to be best principles of usability and accessibility.

On a side-note, should there not be a simple "click to forward upstream" option? Forcing a user make the same effort a second time is far too close to the "you got it wrong, n00b" response far too common in the floss world. The "also affects project" option does not appear to have the right result (which is to let the computer do as much of the work as possible).

Sebastien Bacher (seb128) wrote :

there is no function to automatically send bugs upstream, changes to do that have been discussed several time but that's not something which has been done yet, the tool would probably not copy the bug upstream anyway because making it too easy for users to copy a bug upstream would also mean lowering the quality of the bugs opened there

to come back to the topic I don't agree on what the text option should do, the option is there to not send html text but having all the formatting choices for example is still useful. usually the ubuntu bug triagers send bugs to the upstream bug tracker but in this case you seem to have a strong opinion on the topic and what the option should be doing so it's better if you open the bug there so you can reply to their comment directly rather than having a bug triager who has no opinion on what the option should be doing sending comments between the bug tracker

Peter Whittaker (pwwnow) wrote :

Re no auto-function: fair point. No sense lowering S/N everywhere!

Re opening upstream: Will do. Guess I needed my frustration levels to drop low enough to accept what must be done. I'll try to get that report in within the next few days, then add the link here.

Pedro Villavicencio (pedro) wrote :

Any news about this? did you sent it upstream?

Changed in evolution:
status: New → Incomplete
Peter Whittaker (pwwnow) on 2008-10-27
Changed in evolution:
importance: Undecided → Unknown
status: New → Unknown
Changed in evolution:
status: Incomplete → Triaged
Changed in evolution:
status: Unknown → New
Simon Bridge (simonbridge) wrote :

I can add info to this behavior:

It is not restricted to plain-text mode - also occurs in html.

The inconvenience is that it become impossible to split lines in the quote, say, to insert a reply.

The workaround is to copy the text inside the format box and then past-as-quotation to the end - then erase the entire format box.

Examining the page source when this happens shows me that the original email was formatted using a table. Splitting a line in the quote would involved adding additional tags to end the row, the columb, and the table, then restart it again.

The formatting seems to be to allow some services to add advertising, or other non-user message, to a footer below the email text.

fig_wright (fig-wright) wrote :

I've had this problem since I started using Ubuntu a couple of years ago. It's annoyed me ever since. How can we get these silly formatting "boxes" with dotted lines around them to just go away?

When I create a new email, I already have one of these little boxes covering the first line. This prevents the pasting of text into the email until I delete the formatting box.

Also, when I paste certain things into an email, they appear inside one of these boxes, and then cant be broken up and reformatted...

Where is the "No, when I said NO FORMATTING, I really, honestly, truthfully, meant what I just damned well said" option?

fig_wright (fig-wright) wrote :

Still an issue in Ubuntu 9.04 and Evolution 2.26.1

affects: evolution (Ubuntu) → gtkhtml3.14 (Ubuntu)
Changed in evolution:
importance: Unknown → Undecided
status: New → Invalid
runout (office-runout) wrote :

still open :(

really annoying to have table boxes in a plain text reply.
it's nearly impossible to do inline replys.

so, sebastian, i don't get the point why this should be useful in plain text mode.
this is a bug, not a feature. and this is not windows, we like to work with real text.

Changed in gtkhtml3.14:
status: Unknown → New
Peter Whittaker (pwwnow) wrote :

Can someone explain the status change (from unknown to new)? Just curious. Also curious whether there will be action on this, it continues to be a usability pain. Thanks!

Changed in gtkhtml3.14:
importance: Unknown → Low
Damien (takahara) wrote :

For those who are still having murderous thoughts in 2012 (and likely later), pressing "CTRL-SHIFT-V" (paste quoted text) in the editor window will create a nice block of correct, editable ASCII text. You can use this as follows:

1) highlight the message body in Evolution's main window, CTRL-C
2) hit reply
3) After the "On 2012-09-18 ..... wrote:", hit CTRL-SHIFT-V
4) Wonder at how beautiful ASCII is
5) Promptly terminate the evolution-generated HTML ugliness below.
6) Wonder how longer it will take for devs to realize that inserting HTML in a PLAIN TEXT message is plain stupid.
7) ... Profit!

Changed in gtkhtml3.14:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.