deal with long, outgoing messages

[r10s]

for outgoing messages, currently, it is possible to pass arbitrary long text to dc_msg_set_text() that is also sent with dc_msg_send() then.

however, these outgoing messages cannot be displayed correctly on the sending device after sending as dc_msg_get_text() returns only the first ~30KB of the text; reason is to keep the bubbles usable and also various UI controls get pretty slow if you pass, say 10MB to them.

on the receiving device, things are okay with pr #2264, only the first few KB go to the bubbles and the long text is available with a "Show full message..." button (via dc_msg_has_html()).

(as there is some confusion wrt forwarding here and there: if a message is split into two parts (and has a "Show full message..." therefore), both parts should be forwarded unconditionally)

so, the question is, how to deal with displaying outgoing messages:

1. we could discourage UI to create such long messages, and add an option to find out the max. recommended text len (longer text will still be sent, but will be truncated by dc_msg_get_text())

2. we could split on setting/sending as we do on receiving, however, that may have some side effects for bots (in general, sending some 100KB is no issue, the receiver will deal with that) (on setting is maybe not possible due to drafts that cannot exit html-part)

3. we could let dc_msg_has_html() also check for long, outgoing texts

4. ...

similar to #2213, this issue is also existent forever :)

[Simon-Laux]

maybe send full text as txt attachment instead?

[r10s]

maybe send full text as txt attachment instead?

yip, that is another option.

if done in core automatically, that will have similar issues wrt bots as 2. (solvable, sure). moreover, it might be a bit unexpected to the user, if there appears an attachment suddenly. also api-wise, that is maybe not so super-smart.

otoh, if done on ui-side, that may be better (sort of variation of 1.): if pasting too long texts, ui could inform the user that long text will go into attachments, UI would use the existing api-calls to create the attachment then. not sure, if that is worth the effort, however.

[link2xt]

we could split on setting/sending as we do on receiving, however, that may have some side effects for bots (in general, sending some 100KB is no issue, the receiver will deal with that) (on setting is maybe not possible due to drafts that cannot exit html-part)

I have made a PR #4400 to stop cutting incoming messages for bots. Cutting outgoing messages will break bots and make DC incompatible with other MUAs which will display attachments as attachments.

I think the message should be sent as a normal large text message, both when sent and when forwarded, regardless of what happens locally.

[adbenitez]

I also agree with @link2xt that the outgoing message should not be cut or sent as file,

the real issue with UIs is that core is not doing the same as for received messages (https://github.com/deltachat/deltachat-core-rust/pull/2264) core should offer only a piece of the message and then put the rest under the "show full message" button like for incoming long messages, that will avoid the issues in the UIs rendering that long outgoing messages, (ex. recently an user sent me a DC log by copy+pasting the log text, and that completely freeze his delta chat)

so we could probably close this issue and create a more in-point issue for the "truncating of outgoing message display" if it doesn't exist already