Bug 223616 - Add option to disable formatting in plain-text messages
Summary: Add option to disable formatting in plain-text messages
Alias: None
Product: kmail2
Classification: Unclassified
Component: message list (show other bugs)
Version: 4.9.0
Platform: Debian testing Linux
: NOR wishlist with 20 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
Keywords: junior-jobs
Depends on:
Reported: 2010-01-20 20:30 UTC by Dan Ramaley
Modified: 2012-12-28 07:16 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10

Testcase: mbox file (1.21 KB, application/mbox)
2012-11-24 14:49 UTC, Bernd Oliver Sünderhauf
Testcase rendered in Kmail and Thunderbird (237.54 KB, image/png)
2012-11-24 14:54 UTC, Bernd Oliver Sünderhauf

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Ramaley 2010-01-20 20:30:15 UTC
Version:           1.12.4 (using KDE 4.3.4)
OS:                Linux
Installed from:    Debian testing/unstable Packages

KMail renders text between slashes as italic, text between asterisks as bold, and text between underscores as underlined. It would be great to have an option to disable this behavior and render plain-text as plain-text without any interpretation.
Comment 1 Robert Hofer 2010-03-10 14:52:40 UTC
I dont think this is an entry for the wishlist, it's really a bug. First, you
cant cut and paste correctly like with graphically showed smileys. And second
this "feature" falsify the message, especially if the writer dont intend it. For example if it's a coded text, a symbol, a name...

... type *1234* at your telephon to activate feature XYZ ...
... the product code is *A516111* ...
... the password is *ABCD*
... please print *SuperStore* at the header of the sign ...

tested with kmail 1.13.1
Comment 2 Matthias Wolle 2011-12-30 14:01:14 UTC
still there kmail 1.13.5
Comment 3 Philipp Schmidt 2012-02-21 09:54:25 UTC
Still present in KMail 4.8.0. 

And I agree, this ist definitely a Bug, not a Feature or Wishlist. While it "may" be common (or at least accepted) to format messages this way on the Internet, "Plain text" should really mean just that. If people want real formatting, they can use HTML.
Comment 4 Myriam Schweingruber 2012-08-18 08:18:31 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 5 Luigi Toscano 2012-08-19 00:06:15 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
Comment 6 Philipp Schmidt 2012-08-20 11:37:10 UTC
See my comment above. Currently using 4.9.0 and it is still there. In the configuration there is an option to enable replacing smiliey with emoticons, the same could be done for _underlined_ *fat* and italic text (don't know how that is marked).
Comment 7 Bernd Oliver Sünderhauf 2012-11-24 14:49:10 UTC
Created attachment 75448 [details]
Testcase: mbox file

This is still a wishlist item, rather than a bug, as long as real world testcases, where this otherwise useful (and common) behaviour distorts the message content, can't be fixed appropriately.
I prepared a testcase and comparing Thunderbird and Kmail rendering.

Firstly, Thunderbird renders *bold*, /italics/ and _underscore_ but doesn't remove the markup.
This might be preferable because it ensures no information gets lost, though it is visually less appealing.
So if we stick with our way, we need to be 100% on the secure side.

In more complex cases, both clients to some extent show inconsistentencies, such as:
- the way precendence is handled in multi-formatting, with both browsers showing inconsistencies (why don't we actually render */text/* both italics and bold?)
- Thunderbird render /var/log/ in italics, and *foo*bar* in bold while we don't
- We render numeric-only expressions in bold/italics/whatever, while Thunderbird doesn't
- We render *_foo* bold, but not /*foo* - while Thunderbird does it the other way around.

Firstly, I'd propose to making an informed decision whether we want to keep on removing the markup. If yes, then we need to be more careful about potentially incorrect, potentially complex expressions.
In any case, multi-format rendering should be at least handled in a consistent way, possibly multi-formatted with the exception of /*foo*/ (which is comment markup), or - the other way around - ignoring multiple formatting altogether.
Comment 8 Bernd Oliver Sünderhauf 2012-11-24 14:54:48 UTC
Created attachment 75449 [details]
Testcase rendered in Kmail and Thunderbird
Comment 9 Laurent Montel 2012-11-25 10:11:12 UTC
(In reply to comment #7)
thank for testcase will look at it soon
Comment 10 Laurent Montel 2012-12-28 07:14:31 UTC
Git commit 4a0cc11a2d8c63318cc23d37b3ab3131085838f4 by Montel Laurent.
Committed on 28/12/2012 at 08:13.
Pushed by mlaurent into branch 'KDE/4.10'.

Fix Bug 223616 - Add option to disable formatting in plain-text messages

FIXED-IN: 4.10

Don't add new options. Just don't remove markup as in thunderbird.
so we can copy/paste with loosing infos, and we are sure that
we show exact string.

M  +4    -4    kpimutils/linklocator.cpp

Comment 11 Laurent Montel 2012-12-28 07:16:45 UTC
I decided to not remove "*" "/" etc but change formatting.
I didn't want to add more options.
For multi-format rendering I will look at what I can do.