Replying to email from a plain text domain, the composer uses the default composer for the identity
Email from - say - example.com is always sent in plain text. I therefore want to communicate with people @example.com in plain text. So I added example.com to the list of plain text domains via Tools -> Options -> Composition -> Send options -> Plain text domains.
When I reply to email from example.com, the reply uses the HTML composer, which is the default for the identity that the email was sent to (and therefore that the reply will come from.)
That seems like a silly design choice.
Is this the expected behavior? If not, is there a bug tracking this?
Is there a config setting I can change or an extension I can install that will cause the plain text composer to be used for replies to plain text domains?
I'm using the 2015-07-22 nightly, though I think this behavior goes way back.
Thanks.
P.S. I know that I can click Shift+Reply to use the composer that is the inverse of the default for the identity. It would be nice to not need to do that, because inevitably I forget, and so the process becomes: Click Reply. Notice that it's using the wrong composer. Close message. Command+Click or Control+click Reply. Realize that's not the right way to do it. Close message. Click Shift+Reply. Finally.
เปลี่ยนแปลงโดย IshmaelYavitz เมื่อ
การตอบกลับทั้งหมด (4)
Would it be a problem to uncheck the 'Compose messages in HTML format' box in the 'Manage Identities...' page for that identity? You would then be composing in plain text for All messages for that identity, unless you manually switch composers.
Or, create a new identity for plain text only messages, You can set it up with the same email address, but with slightly different settings. Then select that identity when you compose a plain text message and the composer should change accordingly.
Here are some articles that may help -
http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29 https://support.mozilla.org/en-US/kb/using-identities
gild said
Would it be a problem to uncheck the 'Compose messages in HTML format' box in the 'Manage Identities...' page for that identity? You would then be composing in plain text for All messages for that identity, unless you manually switch composers.
Yes. example.com is the only plain text domain, so doing that would result in more work.
gild said
Or, create a new identity for plain text only messages, You can set it up with the same email address, but with slightly different settings. Then select that identity when you compose a plain text message and the composer should change accordingly.
Interesting suggestion.
I'm going to continue to maintain that Thunderbird's current behavior is at worst a bug, and at best a concession to novice users ("Why when I'm replying to email does it sometimes use the HTML composer and sometimes use the text composer?!?!") that should be overridable via a config setting that, in effect, communicates, "Yes, I understand that by putting domains in the plain text domain list it means that I'll be shown the text composer."
My understanding is that since Mozilla hung Thunderbird out to dry, there is no longer any paid staff working on it?
Do any TB developers or team members read this forum? If not, I'll just open a bug on bugzilla rather than waiting to see if anyone knows of an existing bug number...
Thanks,
Ish
IshmaelYavitz said
gild saidOr, create a new identity for plain text only messages, You can set it up with the same email address, but with slightly different settings. Then select that identity when you compose a plain text message and the composer should change accordingly.Interesting suggestion.
So, I just tested this (though using identities with different default mail formats) and it doesn't work that way. Switching between identities with different default formats (text/HTML) doesn't change the composer.
เปลี่ยนแปลงโดย IshmaelYavitz เมื่อ
Looks like a bug in TB. Even in safe mode, identities do not work as they used to. In the past, I could change HTML/text mode, signatures, and even change SMTP servers. Now, except for the identity name on new writes, everything seems to be locked into the Main Account Settings.