truncate incoming messages by lines

[Simon-Laux]

because many line-breaks seem to cause the chat open delay on deltachat-ios. (https://github.com/deltachat/deltachat-core-rust/issues/3478)

I only starts counting lines if text is longer than DC_DESIRED_TEXT_LINES_THRESHOLD, so should not have an speed impact for most messages.

I already tested this on iOS and it worked as expected there.

The old truncate function is still used for message-info(we might remove message text there) and chat summary (will stay for summary).

TODO / Things to consider:

• [ ] I'm did not do any benchmarks, maybe there are some rust tricks to make it more performant, but its probably already fast enough
• [ ] I'm not sure if I converted @dignifiedquire's unicode edge texts correctly

closes #3478

[link2xt]

I'm not sure if I converted dignifiedquire's unicode edge texts correctly

Do you mean the truncate_by_lines tests? Are they copied/converted from somewhere?

[r10s]

first, of all, thanks for pushing this forward.

for 1.32, i suggest to not merge this in, there are some open question and the pr affects very basic things that are better tested a bit longer.

is the number of linebreaks really identified as the slowdown issue? there is a "seems" in the intial sentence :)

for https://github.com/deltachat/deltachat-core-rust/issues/3478, the gist is also to cut long messages at all, independently of the number of lines and also maybe truncate before the first "large" link occurs. these messages are usually unreadable anyway and better read in full html-view.

[Simon-Laux]

I'm not sure if I converted dignifiedquire's unicode edge texts correctly

Do you mean the truncate_by_lines tests? Are they copied/converted from somewhere?

yeah mostly copied and adapted a bit

[link2xt]

is the number of linebreaks really identified as the slowdown issue? there is a "seems" in the intial sentence :)

It does not really matter if linebreaks make rendering slow on iOS. It makes sense to truncate messages after a certain number of linebreaks anyway, because otherwise it is possible to make a message consisting of 3000 linebreaks that will occupy several screens even if it is considered "short" by the number of characters.

Adding a separate line limit in addition to character limit makes sense in any case.

It doesn't fix #3478 though, because #3478 is also about URLs with lots of tracking parameters, so I'm removing "closes" from the first message.

[link2xt]

@Simon-Laux I reworded error message a bit and fixed the tests.