I have set "Compose HTML messages" to "Never", because that is what I want.
I'm a bit confused with regards to plain text replies to messages with a text/html and a text/plain part. Roundcube often (but not always) seems to quote the text/html part rather than the text/plain part. This often leads to really ugly replies/quotes with tons of useless/duplicated links at the end of the message (while the links within the message are sometimes being removed).
See message attached. Is this intentional...? (Well, hopefully not)
If replying to a HTML only message, Roundcube has of course no other choice than replying to the HTMl part. But in this case I'm still wondering why all links contained in the message are being duplicated at the end of the message with "[1]", "[2]" and so on, and sometimes even being removed within the message text (as can be seen with the attached message). It's a bit of an annoyance to remove these links at the end of the message and the "[1]", "[2]" etc. within the message text.
Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?) Or is it a duplicate to "on reply to HTML message only"?.
Last but not least, in very few and exceptional cases I'd indeed like to compose a HTML message when replying to a HTML message. Currently I see no other way than to change the option "Compose HTML messages", create the reply, and then reset "Compose HTML messages" back to "Never" (which I then sometimes forget, of course, and which is not too comfortable).
Of course I can change the editor type AFTER clicking the reply button, but then all HTML tags of the quoted message are still lost. I currently have no good idea for a UI for this, but a function to reload the HTML part into the message editor (or to load the HTML part upfront after the user has - in which way ever - clearly stated that he exceptionally wants to create a HTML message) would just be great.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
I just realized that the whole thing is also related to the user config setting "Display HTML" in the "Displaying messages" section. If disabled, Roundcube DOES reply to the text/plain part (if at the same time "Compose HTML messages" is set to "Never").
But my user config is:
Display HTML: enabled Compose HTML messages: Never
And in this case the behaviour quoted in the message below does apply.
While looking into this, even more issues came up:
If "Display HTML" is disabled, I see the text/plain part. Optional, I can click on the "HTML message" link to display the text/html part. This is great, but:
a) If I click on the link "HTML message", the HTML message is (of course) being loaded, but along with all remote images without any warning (and although I didn't explicitely allow Roundcube to load those images). This is in contradiction to the situation when "Display HTML" is ENABLED, where those images are NOT loaded by default. So enabling this option is more secure than disabling it...?
b) Vice versa ("Display HTML" being enabled) I do NOT get a link to display the text/plain part. But if this link would exist, THIS could do the trick with regards to if I will reply with a HTML or a plain text message (and which part of the message will be quoted). At least I should have the chance to VIEW the text/plain part, even if "Display HTML" is enabled.
I do not have a final concept at hand, but would you agree that some redesign is needed here...?
If so, I'm happy to cooperate (I can just not code the stuff, but I may be able to work on the desired logic).
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 17.11.2012 20:26, Michael Heydekamp wrote:
I have set "Compose HTML messages" to "Never", because that is what I want.
I'm a bit confused with regards to plain text replies to messages with a text/html and a text/plain part. Roundcube often (but not always) seems to quote the text/html part rather than the text/plain part. This often leads to really ugly replies/quotes with tons of useless/duplicated links at the end of the message (while the links within the message are sometimes being removed).
See message attached. Is this intentional...? (Well, hopefully not)
If replying to a HTML only message, Roundcube has of course no other choice than replying to the HTMl part. But in this case I'm still wondering why all links contained in the message are being duplicated at the end of the message with "[1]", "[2]" and so on, and sometimes even being removed within the message text (as can be seen with the attached message). It's a bit of an annoyance to remove these links at the end of the message and the "[1]", "[2]" etc. within the message text.
Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?) Or is it a duplicate to "on reply to HTML message only"?.
Last but not least, in very few and exceptional cases I'd indeed like to compose a HTML message when replying to a HTML message. Currently I see no other way than to change the option "Compose HTML messages", create the reply, and then reset "Compose HTML messages" back to "Never" (which I then sometimes forget, of course, and which is not too comfortable).
Of course I can change the editor type AFTER clicking the reply button, but then all HTML tags of the quoted message are still lost. I currently have no good idea for a UI for this, but a function to reload the HTML part into the message editor (or to load the HTML part upfront after the user has - in which way ever - clearly stated that he exceptionally wants to create a HTML message) would just be great.
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On 11/18/2012 01:26 AM, Michael Heydekamp wrote:
I just realized that the whole thing is also related to the user config setting "Display HTML" in the "Displaying messages" section. If disabled, Roundcube DOES reply to the text/plain part (if at the same time "Compose HTML messages" is set to "Never").
Yes. This is by design. If you view the message as HTML we use the same part for response. It's because text and html part may differ. I think it's better to use on reply the same part which was viewed.
If "Display HTML" is disabled, I see the text/plain part. Optional, I can click on the "HTML message" link to display the text/html part. This is great, but:
a) If I click on the link "HTML message", the HTML message is (of course) being loaded, but along with all remote images without any warning (and although I didn't explicitely allow Roundcube to load those images). This is in contradiction to the situation when "Display HTML" is ENABLED, where those images are NOT loaded by default. So enabling this option is more secure than disabling it...?
This might be a bug. Create a ticket in our bugtracker.
b) Vice versa ("Display HTML" being enabled) I do NOT get a link to display the text/plain part. But if this link would exist, THIS could do the trick with regards to if I will reply with a HTML or a plain text message (and which part of the message will be quoted). At least I should have the chance to VIEW the text/plain part, even if "Display HTML" is enabled.
I do not have a final concept at hand, but would you agree that some redesign is needed here...?
I agree, it would be good to have a html/text switching button in message preview pane. Would you like to work on a patch?
Am 18.11.2012 08:55, schrieb A.L.E.C:
On 11/18/2012 01:26 AM, Michael Heydekamp wrote:
I just realized that the whole thing is also related to the user config setting "Display HTML" in the "Displaying messages" section. If disabled, Roundcube DOES reply to the text/plain part (if at the same time "Compose HTML messages" is set to "Never").
Yes. This is by design. If you view the message as HTML we use the same part for response. It's because text and html part may differ.
Well, they HAVE to differ by definition, IMO. Otherwise it wouldn't make sense to have a text/html and a text/plain part, if there would be nil difference.
But the text part of a HTML message is by far the better formatted and "quotable" part than the HTML part, being stripped and re-formatted by Roundcube or any other MUA. See the newsletter that I attached to my original post, the quote is just ridiculous.
I think it's better to use on reply the same part which was viewed.
And I think that the text/plain part is there for some reason: One of them being that it should be the one to be quoted if composing a text/plain reply. (The other one being that it can be viewed with MUAs not being HTML-capable.)
If "Display HTML" is disabled, I see the text/plain part. Optional, I can click on the "HTML message" link to display the text/html part. This is great, but:
a) If I click on the link "HTML message", the HTML message is (of course) being loaded, but along with all remote images without any warning (and although I didn't explicitely allow Roundcube to load those images). This is in contradiction to the situation when "Display HTML" is ENABLED, where those images are NOT loaded by default. So enabling this option is more secure than disabling it...?
This might be a bug. Create a ticket in our bugtracker.
Will do.
b) Vice versa ("Display HTML" being enabled) I do NOT get a link to display the text/plain part. But if this link would exist, THIS could do the trick with regards to if I will reply with a HTML or a plain text message (and which part of the message will be quoted). At least I should have the chance to VIEW the text/plain part, even if "Display HTML" is enabled.
I do not have a final concept at hand, but would you agree that some redesign is needed here...?
I agree, it would be good to have a html/text switching button in message preview pane. Would you like to work on a patch?
Absolutely! But...
Unfortunately I can't. As I said already in my original post (that part you didn't quote, not sure if you did read it):
If so, I'm happy to cooperate (I can just not code the stuff, but I may be able to work on the desired logic).
My PHP/js skills are close to zero, you should be grateful if I don't touch the Roundcube code at all. ;) And my BP skills wouldn't help here, I'm afraid.
So I'm totally dependent on you guys and can just propose sense-making suggestions here and there...
Anyway, thanks to the Roundcube dev team for the great job (some things need to be said sometimes)
On 11/18/2012 11:13 PM, Michael Heydekamp wrote:
Yes. This is by design. If you view the message as HTML we use the same part for response. It's because text and html part may differ.
Well, they HAVE to differ by definition, IMO. Otherwise it wouldn't make sense to have a text/html and a text/plain part, if there would be nil difference.
But the text part of a HTML message is by far the better formatted and "quotable" part than the HTML part, being stripped and re-formatted by Roundcube or any other MUA. See the newsletter that I attached to my original post, the quote is just ridiculous.
I do not agree. I think it's better to quote on reply the same content we see when previewing the message. So, if we preview in HTML we use html part, if in text we use text part. I saw many messages that had totally different text part or even empty (but existing).
If someone create a patch which implements an option to change this behaviour via user preferences, we would likely accept it, however.
Am 19.11.2012 08:12, schrieb A.L.E.C:
On 11/18/2012 11:13 PM, Michael Heydekamp wrote:
But the text part of a HTML message is by far the better formatted and "quotable" part than the HTML part, being stripped and re-formatted by Roundcube or any other MUA. See the newsletter that I attached to my original post, the quote is just ridiculous.
I do not agree. I think it's better to quote on reply the same content we see when previewing the message. So, if we preview in HTML we use html part, if in text we use text part. I saw many messages that had totally different text part or even empty (but existing).
That's an argument. Taken.
If someone create a patch which implements an option to change this behaviour via user preferences, we would likely accept it, however.
In the meantime I think that such an option isn't even needed. We would "just" (yeah, I know...) need this button which switches between plain text and HTML part (given that both parts do exist at all), and the reply goes to the part which has been viewed last.
Another issue is in which style (HTML or text) the reply (and the quote!) will be created. The default should be that HTML parts will be quoted and replied in HTML style, and that plain text parts will be quoted and replied in plain text - but there should be an option to change the style BEFORE the message is being quoted and edited (without being forced to change and reset the user config).
Sounds pretty complex, I know...
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 18.11.2012 23:13, schrieb Michael Heydekamp:
Am 18.11.2012
08:55, schrieb A.L.E.C:
On 11/18/2012 01:26 AM, Michael Heydekamp
wrote:
I just realized that the whole thing is also related to
the user config setting "Display HTML" in the "Displaying messages" section. If disabled, Roundcube DOES reply to the text/plain part (if at the same time "Compose HTML messages" is set to "Never").
Yes. This
is by design. If you view the message as HTML we use the same part for response. It's because text and html part may differ.
Well, they
HAVE to differ by definition, IMO. Otherwise it wouldn't make
sense to
have a text/html and a text/plain part, if there would be nil
difference.
But the text part of a HTML message is by far the
better formatted and
"quotable" part than the HTML part, being
stripped and re-formatted by
Roundcube or any other MUA.
Why should it be better formatted (Except maybe in some very exceptional cases where both parts have been created individually)? Usually the text part is just a stripped and reformatted version of the HTML part, only that this has already been done by the mail client when the HTML message was composed. So where is the difference...?
See the newsletter that I
attached to my original post, the quote is just ridiculous.
I
think it's better to use on reply the same part which was viewed.
And I think that the text/plain part is there for some reason: One of them
being that it should be the one to be quoted if composing a
text/plain
reply. (The other one being that it can be viewed with MUAs
not being
HTML-capable.)
No, you need to use the part being displayed for quoting when composing a reply. As has been said before text and html part sometimes differ, not only in formatting but also the content may be completely different! E.g. it could contain just a link to read the newletter online or be just some default text, etc.
b) Vice versa ("Display HTML" being enabled)
th regards to if I will reply with a
HTML or a plain text message (and which part of the message will be quoted). At least I should have the chance to VIEW the text/plain part, even if "Display HTML" is enabled. I do not have a final concept at hand, but would you agree that some redesign is needed here...?
I
agree, it would be good to have a html/text switching button in message preview pane.
Yes, this is something which I believe is really
missing. One option could be to show the unused part as attachment and clicking on it chooses this part.
Manfred
Am 19.11.2012 08:22, schrieb Manfred Usselmann:
Am 18.11.2012 23:13, schrieb Michael Heydekamp:
But the text part of a HTML message is by far the better formatted and "quotable" part than the HTML part, being stripped and re-formatted by Roundcube or any other MUA.
Why should it be better formatted (Except maybe in some very exceptional cases where both parts have been created individually)? Usually the text part is just a stripped and reformatted version of the HTML part, only that this has already been done by the mail client when the HTML message was composed. So where is the difference...?
Well, look at the newsletter I attached to my original post, and try to quote it.
Do you see the difference or shall I demonstrate it here?
See the newsletter that I attached to my original post, the quote is just ridiculous.
No, you need to use the part being displayed for quoting when composing a reply.
But currently I have no chance to display (and reply to) the text/plain part, when "Display HTML" is enabled! I thought I made that quite clear already.
As has been said before text and html part sometimes differ, not only in formatting but also the content may be completely different! E.g. it could contain just a link to read the newletter online or be just some default text, etc.
You're right. So it would indeed be the best option to be able to switch between both parts and then decide which one the user wants to reply to (no matter if "Display HTML" is being the default view or not).
b) Vice versa ("Display HTML" being enabled)
th regards to if I will reply with a HTML or a plain text message [...]
Uh, what's this now...?!!
The quote above is missing a lot of text between "[...] being enabled)" and "th regards to [...]" The missing text is:
" I do NOT get a link to display the text/plain part. But if this link would exist, THIS could do the trick wi" This text can be seen in your reply, but it's gone in my quote of your reply.
Where the heck did this text go to? This is scaring me...
As can be seen in this example, it is more than obvious that quoting HTML messages needs some major improvements. Losing content upon quoting is barely acceptable.
And if I look at the source of your message, even the quoting in the text/plain part is way beyond how a decent quoting in a plain text message should look like. <shrug> But that may be a browser issue (displaying the source) and I need to dig deeper into this issue before blaming Roundcube.
(and which part of the message will be quoted). At least I should have the chance to VIEW the text/plain part, even if "Display HTML" is enabled. I do not have a final concept at hand, but would you agree that some redesign is needed here...?
Uh again - this quote does have just one "> " at the beginning of the paragraph, the rest of the paragraph is "flowed" (unlike to the quote of the first paragraph of your message above). This is confusing me.
We'll see how that will be looking if I'm now gonna send this mail (with our default 'format_flowed = false')...
Am 19.11.2012 20:41, schrieb Michael Heydekamp:
(and which part of the message will be quoted). At least I should have the chance to VIEW the text/plain part, even if "Display HTML" is enabled. I do not have a final concept at hand, but would you agree that some redesign is needed here...?
Uh again - this quote does have just one "> " at the beginning of the paragraph, the rest of the paragraph is "flowed" (unlike to the quote of the first paragraph of your message above). This is confusing me.
We'll see how that will be looking if I'm now gonna send this mail (with our default 'format_flowed = false')...
Well, it looks OK in Roundcube insofar as the entire paragraph is displayed as a quoted paragraph in flowed style, see attached image.
But this is a HTML-based and format_flowed-aware display, most text based MUAs would likely display it this way:
(and which part of the message will be quoted). At least I should have the
chance to VIEW the text/plain part, even if "Display HTML" is enabled. I do not have a final concept at hand, but would you agree that some redesign is needed here...?
Apart from that, we have two open questions in this respect:
- Why is especially this paragraph of the original message quoted in
flowed style upon replying, but all others are not (although they are identically formatted in the original message)?
- Why is 'format_flowed = false' apparently ignored upon sending?
But even more important is this issue, of course:
b) Vice versa ("Display HTML" being enabled)
th regards to if I will reply with a HTML or a plain text message [...]
Uh, what's this now...?!!
The quote above is missing a lot of text between "[...] being enabled)" and "th regards to [...]" The missing text is:
" I do NOT get a link to display the text/plain part. But if this link would exist, THIS could do the trick wi" This text can be seen in your reply, but it's gone in my quote of your reply.
Where the heck did this text go to? This is scaring me...
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 19.11.2012 23:04, schrieb Michael Heydekamp:
But even more important is this issue, of course:
b) Vice versa ("Display HTML" being enabled)
th regards to if I will reply with a HTML or a plain text message [...]
Uh, what's this now...?!!
The quote above is missing a lot of text between "[...] being enabled)" and "th regards to [...]" The missing text is:
" I do NOT get a link to display the text/plain part. But if this link would exist, THIS could do the trick wi" This text can be seen in your reply, but it's gone in my quote of your reply.
Where the heck did this text go to? This is scaring me...
JFTR:
Although nobody replied to this issue explicitely, the problem seems to have gone in the meantime. At least I can't replicate it with the current 0.9-git anymore.
I can still replicate it with 0.8.4, though. Wondering, which commit might have (unintentionally?) fixed that.
The message related to this issue is the one of Manfred Usselmann of 19.11.2012, 08:22, in this list. A reply to this message brought up the issue of the lost text part in the quote.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 19.11.2012 08:22, schrieb Manfred Usselmann:
Am 18.11.2012 23:13, schrieb Michael Heydekamp:
Yes, this is something which I believe is really missing. One option could be to show the unused part as attachment and clicking on it chooses this part.
BTW: Your message shows the attachment symbol (the "Büroklammer" aka paper clip), but I can't find any attachment.
Is this different elsewhere...? Looks like another HTML issue to me.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 18.11.2012 08:55, schrieb A.L.E.C:
On 11/18/2012 01:26 AM, Michael Heydekamp wrote:
a) If I click on the link "HTML message", the HTML message is (of course) being loaded, but along with all remote images without any warning (and although I didn't explicitely allow Roundcube to load those images). This is in contradiction to the situation when "Display HTML" is ENABLED, where those images are NOT loaded by default. So enabling this option is more secure than disabling it...?
This might be a bug. Create a ticket in our bugtracker.
Done, see http://trac.roundcube.net/ticket/1488827
Although it's a major hassle to create a ticket, this bugtracker is complaining about almost everything (even the term "MESSAGE").
On 11/17/2012 08:26 PM, Michael Heydekamp wrote:
Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?)
German? https://translations.launchpad.net/roundcubemail/trunk/+pots/labels/de/+tran... Please, update localization yourself and don't ask again about untranslated labels.
Am 18.11.2012 09:09, schrieb A.L.E.C:
On 11/17/2012 08:26 PM, Michael Heydekamp wrote:
Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?)
German? https://translations.launchpad.net/roundcubemail/trunk/+pots/labels/de/+tran... Please, update localization yourself
Thanks for the link, I wasn't aware of it at all till I saw your post this morning.
and don't ask again about untranslated labels.
I'll keep asking whenever I have a question, if you don't mind. ;)
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 17.11.2012 20:26, schrieb Michael Heydekamp:
If replying to a HTML only message, Roundcube has of course no other choice than replying to the HTMl part. But in this case I'm still wondering why all links contained in the message are being duplicated at the end of the message with "[1]", "[2]" and so on, and sometimes even being removed within the message text (as can be seen with the attached message). It's a bit of an annoyance to remove these links at the end of the message and the "[1]", "[2]" etc. within the message text.
I believe this is to show the actual URL of the link when the text of the link and the URL it points to are different. May be this can be improved a bit and the footnote omitted in case there is no different text for the link.
Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?) Or is it a duplicate to "on reply to HTML message only"?.
The last one "on forward or reply to HTML message" is something I would like to use but I don't see it. How can I activate it?
Manfred
On 11/17/2012 08:26 PM, Michael Heydekamp wrote: ...
Furthermore, the option "Compose HTML messages" has apparently four options now, the last one ("on forward or reply to HTML message") not being localized (yet?) Or is it a duplicate to "on reply to HTML message only"?.
Last but not least, in very few and exceptional cases I'd indeed like to compose a HTML message when replying to a HTML message. Currently I see no other way than to change the option "Compose HTML messages", create the reply, and then reset "Compose HTML messages" back to "Never" (which I then sometimes forget, of course, and which is not too comfortable).
...
All this seems to get fairly messy. I would have thought the compose style option should be a fairly clear-cut option: 'text' or 'HTML'.
Just an FYI as Mozilla Thunderbird is often quoted as a reference for how clients can function.
In Thunderbird, I have 'text' as my default compose method.
Text is used, per default, upon compose and reply (irrelevant of what is being displayed (text/HTML)).
You can 'simply' switch your compose style by 'shift-clicking' the 'Write' or 'Reply' buttons and it will, in my case, switch to HTML (or text if HTML is default).
This could be used as a documented UI option for choosing compose/response style (plus tool-tip). I believe that the default should be that that the user has selected in their preferences. Making a HTML reply just because I am viewing a HTML message is not following the users composition preferences.
This would solve most of the above stated issues in a simple and consistent manner. It could also be argued that multiple sub-options for HTML would then no longer be needed.
Regards
Chris
-
A.L.E.C -
Chris Moules -
Manfred Usselmann -
Michael Heydekamp