Usage of options "Reply using HTML if present" and "Options -> Formatting (HTML)" clash a bit: when "Reply using HTML if present" is unchecked and "Options -> Formatting (HTML)" is checked from the last time, the quotation of an HTML e-mail is made plain-text ("Reply using HTML if present" off), but the reply itself is still HTML ("Options -> Formatting (HTML)" on). It would be more logical if the composer would be put to plain-text mode when replying with plain-text. I understand that this breaks the current usage of "Options -> Formatting (HTML)" - the principle that it should always be the same state as it was the last time. Or is there such a principle at all? If not, dynamically setting this option to on/off would not be a problem, I guess? Reproducible: Always Steps to Reproduce: 1. Check "Options -> Formatting (HTML)" 2. Uncheck "Reply using HTML if present" 3. Start replying to an HTML e-mail Actual Results: Composer is in HTML mode Expected Results: Composer is in pain-text mode
"the principle that it should always be the same state as it was the last time" we use it. So we will not change it. Sorry
OK, if it is really so important to keep the option always the same. Another possibility to make switching between plain-text and HTML replies better, is still waiting feedback in bug 316917. And yet another is to make a toolbar button for setting "Reply using HTML if present". What do you think about this?
(In reply to comment #1) > "the principle that it should always be the same state as it was the last > time" we use it. Actually it is not true: 1. Check "Reply using HTML if present" 2. Uncheck "Options -> Formatting (HTML)" 3. Start replying to a HTML e-mail -- "Reply using HTML if present" is checked by itself So there is no such principle and thus, why not implement the 1st idea?
(In reply to comment #3) > 3. Start replying to a HTML e-mail -- "Reply using HTML if present" is > checked by itself Sorry, I meant that "Options -> Formatting (HTML)" is checked by itself.
Oh, and option "Reply using HTML if present" goes for forwarding e-mail too. I guess the name of the option should be "Reply/forward using HTML if present" then?
It is good to use html by default when replying to HTML. problem is that HTML then is "stuck" when composing a new message. one idea is to have a new applicatio option for "Compose New Messages in HTML" Another thought is to have a toolbar button on the composer for switching to/from html
Actually there is a feature request for both of these ideas: bug 317227 :)
(In reply to comment #7) > Actually there is a feature request for both of these ideas: bug 317227 :) Sorry, bug 316917
in 4.11, there will be a button conveniently located on the composer toolbar that allows toggling between plaintext and richtext. Laurent is not willing to add a new option for "Compose New Messages in HTML" so resolving this one.
Well, this bug is certainly not "fixed" if nothing was changed, is it? My first idea was that composer should be put into plain-text mode if e-mail that it is replying to is plain-text only. So it does not need a new button.
When a stored message has both plaintext and HTML parts, a user can pick which part to look at (easily, if they enable the message structure pane); I expected (hoped, I should say -- there was no real reason to expect) that the format of the reply will be set according to the part I am looking at when I hit "reply". That is, reply in plain-text if I'm looking at the plaintext, reply in HTML to the HTML. a) Any chance? b) Assuming "yes", would you consider that a partial solution to this ticket, or should I open a new wish? Thanks, Shai.
Well, this could be considered as another workaround indeed, but the original usage error in this bug report still remains.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.