I'd like to implement this feature, but maybe we could also do some unification in editor type handling. Let's see what we should do in compose modes:
- NEW: Here we're using htmleditor option, to enable/disable HTML
editor. No problem here.
- DRAFT and EDIT-AS-NEW: Here we should use format of draft/edited
message. No problem here.
- REPLY: Now we're lacking something here and current behaviour is not
100% consistent. So, what we can do? Use htmleditor setting no matter what is format of replied message? No. Here's my proposal. We could extend htmleditor option to 3-option switch:
- 'never', (0)
- 'only on reply to HTML message', (2)
- 'always' (1).
I think this is self explanatory. When 0, we'll always disable HTML editor, when 1 we'll always enable HTML editor, when 2 we'll enable HTML editor only when replied message is in HTML format.
Here I see one backward incompatible change. Currently when htmleditor=true and we're reply to plain text message, the editor will be disabled.
- FORWARD: Here I'm not sure, but I think editor should be set like for
NEW/EDIT mode. When we implement "forward-as-attachment" we should set editor like for NEW message.
ps. in future we could add some per-contact format setting (like in Thunderbird).
Hi Alec,
On 2010-10-06 08:47 UTC A.L.E.C wrote:
I'd like to implement this feature, but maybe we could also do some unification in editor type handling. Let's see what we should do in compose modes:
- NEW: Here we're using htmleditor option, to enable/disable HTML
editor. No problem here.
- DRAFT and EDIT-AS-NEW: Here we should use format of draft/edited
message. No problem here.
- REPLY: Now we're lacking something here and current behaviour is not
100% consistent. So, what we can do? Use htmleditor setting no matter what is format of replied message? No. Here's my proposal. We could extend htmleditor option to 3-option switch:
- 'never', (0)
- 'only on reply to HTML message', (2)
- 'always' (1).
I think this is self explanatory. When 0, we'll always disable HTML editor, when 1 we'll always enable HTML editor, when 2 we'll enable HTML editor only when replied message is in HTML format.
Here I see one backward incompatible change. Currently when htmleditor=true and we're reply to plain text message, the editor will be disabled.
- FORWARD: Here I'm not sure, but I think editor should be set like for
NEW/EDIT mode. When we implement "forward-as-attachment" we should set editor like for NEW message.
I like your proposal. I think this backwards incompatibility is no big deal.
ps. in future we could add some per-contact format setting (like in Thunderbird).
I always thought the per-contact format setting was overkill - something nobody actually uses. Either you have your principles and only write plain- text messages, or you don't care and use the default setting (which sends mails in both plain-text and HTML version, AFAIK).
Patrick.
A.L.E.C wrote:
[...]
- REPLY: Now we're lacking something here and current behaviour is not
100% consistent. So, what we can do? Use htmleditor setting no matter what is format of replied message? No. Here's my proposal. We could extend htmleditor option to 3-option switch:
- 'never', (0)
- 'only on reply to HTML message', (2)
- 'always' (1).
I think this is self explanatory. When 0, we'll always disable HTML editor, when 1 we'll always enable HTML editor, when 2 we'll enable HTML editor only when replied message is in HTML format.
Here I see one backward incompatible change. Currently when htmleditor=true and we're reply to plain text message, the editor will be disabled.
This sounds reasonable and I don't worry about this little incompatibility. People can easily change it in their prefs. Also true wour be 1 and therefore it's more like a fix because one might expect to write HTML replies already now.
- FORWARD: Here I'm not sure, but I think editor should be set like for
NEW/EDIT mode. When we implement "forward-as-attachment" we should set editor like for NEW message.
Agree. Forward mails according to user settings and with forward-as-attachment we'd have the message forwarded without any loss.
ps. in future we could add some per-contact format setting (like in Thunderbird).
Not a killer-feature for me. I usually don't care what my contacts prefer but just write plaintext e-mails.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 06.10.2010 14:47, Thomas Bruederli wrote:
ps. in future we could add some per-contact format setting (like in Thunderbird).
Not a killer-feature for me. I usually don't care what my contacts prefer but just write plaintext e-mails.
Me too, but I can imagine one use case. When somebody uses HTML by default, but has some contacts (this for example could be a mailing list) that doesn't like HTML. But we can live without this ;) Just an idea from Thunderbird.
2010.10.06 11:47, A.L.E.C rašė:
I'd like to implement this feature, but maybe we could also do some unification in editor type handling. Let's see what we should do in compose modes:
- NEW: Here we're using htmleditor option, to enable/disable HTML
editor. No problem here.
- DRAFT and EDIT-AS-NEW: Here we should use format of draft/edited
message. No problem here.
- REPLY: Now we're lacking something here and current behaviour is not
100% consistent. So, what we can do? Use htmleditor setting no matter what is format of replied message? No. Here's my proposal. We could extend htmleditor option to 3-option switch:
- 'never', (0)
- 'only on reply to HTML message', (2)
- 'always' (1).
I think this is self explanatory. When 0, we'll always disable HTML editor, when 1 we'll always enable HTML editor, when 2 we'll enable HTML editor only when replied message is in HTML format.
Here I see one backward incompatible change. Currently when htmleditor=true and we're reply to plain text message, the editor will be disabled.
- FORWARD: Here I'm not sure, but I think editor should be set like for
NEW/EDIT mode. When we implement "forward-as-attachment" we should set editor like for NEW message.
I suggest EDIT mode when forwarding.
ps. in future we could add some per-contact format setting (like in Thunderbird).
What I think could be more useful (and is also at Thunderbird feature) is to try to figure out whether or not the composed message actually contains any styling, and then either send it as plain text or as multipart/alternative. Is it done now? If not, is it possible?
Rimas
List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
A.L.E.C -
Patrick Nagel -
Rimas Kudelis -
Thomas Bruederli