Optimal line splitting

[JustAnotherArchivist]

As I understand it, irc-framework currently splits messages based on a fixed maximum length of the actual message. The default value for that is only 350, resulting in too frequent splits: with an average channel name of 15 ASCII characters, a PRIVMSG is 375 bytes with the current default settings (7 B command + 1 B space + 15 B channel name + 1 B space + 1 B colon + 350 B message), even though it could safely contain 38.6 % more message text, namely 510 B - 7 B command - 1 B space - 15 B channel name - 1 B space - 1 B colon = 485 B.

I suggest it should split the messages optimally such that each IRC protocol message, i.e. including command and target, is as close to the permitted 510 bytes (not 500 as claimed by a code comment) as possible – without splitting words/graphemes/codepoints of course.

[digitalcircuit]

Though I'm unsure of how easily it can be ported to JavaScript given it makes use of Qt's text handling, it might be worthwhile looking at Quassel IRC's line splitting code, too, as does most if not all of the calculations suggested above.

Main locations of interest:

• CoreNetwork::splitMessage()
  • Word/grapheme/codepoint-aware splitting logic
• CoreUserInputHandler::lastParamOverrun()
  • Context/hostmask-aware calculation of whether or not a line needs split

[adedomin]

This change has broken my use case as well. coming from 2.9.1, I tried upgrading to 4.9.0.

results are as followed:

2.9.1:

4.9.0:

If it were configurable, I wouldn't be all that upset with it. Would be open to do the PR.
edit: I guess it is configurable, but not documented.