Frederick888
commented
10 months ago Thanks but I can't say I'm a fan of this idea.
First of all, writing HTML emails with EER, despite being rarer, is still a valid use case.
Secondly, to avoid having a breaking change, it has to be configurable and by default off. So users will have to go through this step anyway, and it only makes the already appallingly long Wiki even longer.
Further, plain text email lovers are probably gonna have to uncheck Compose messages in HTML format anyway. Otherwise replies will be in HTML by default. To make matters worse, 'the compose format of an existing compose window cannot be changed', so the 'Enable Plain Text Only in EER -> Click on Reply -> Reply in HTML -> Click on EER -> Reply in Plain Text' workflow simply does not exist. And by the way even if you do the same thing to beginReply calls (keyboard shortcut flow), the 'Click on Reply -> EER' flow still needs to be consistent, since the keyboard shortcut (inherently) cannot always choose the correct email to reply to. Of cos the setting can specifically say it only affects new emails, but if you send such an email, get a reply, then click on reply to respond, then EER just stops enforcing plain text? That doesn't sound right to me.
Finally this new setting can be confusing. If you uncheck Compose messages in HTML, this setting, provided being a checkbox, suddenly doesn't do anything any more? If the setting is a dropdown (unset, HTML, plain text), I mean... And I haven't got the time to check how well this plays with Delivery Format...
Really unchecking one account setting is one of the easiest parts of the whole setup, and considering all above, I'd rather just leave it to users. KISS (keep it simple, stupid) :)
Description
Instead of asking users to configure Thunderbird to compose all emails in plain text (as you currently do in the wiki), always compose in plain text when using the button.
If required, I can make this configurable.
Changes
Checklist
Is this a breaking change?
I don't know.
Test results