Forums Feature Suggestions "Split Long Channel / Query Messages" too short

The Options (Alt+O) > IRC > Messages > [x] Split long channel/query messages option is arguably too conservative, splitting lines at 300 bytes (or only 100~150 UTF-8 characters) considering the larger and wider displays of today.

I would suggest increasing this value to 400, with an edit box for a custom value. I personally want a value of 460 for myself, so I have turned off this option. It especially interferes with creative forms of expression, like highly colorized ASCII / mIRC Art. (Old school text art is all the rage again.)

I believe the theoretical maximum PRIVMSG command is 162 bytes, out of 512 bytes, which leaves at minimum 350 bytes for messages... even if you have a 25 character nickname, a 10 character ident, a 63 character hostname, and are joined to a 50 character channel name.

:123456789_123456789_12345!123456789_@123456789_123456789_123456789_123456789_123456789_123456789_123 PRIVMSG #123456789_123456789_123456789_123456789_123456789 :<350 character message here>

It should also be possible for mIRC to automatically adjust this value by predicting the line length by adding all of these values together as mentioned above.

var %msgwraplen = $calc(512 - $len(: $+ $ial($me) PRIVMSG $chan :))

I just tested this, checked the /debug output, and the outgoing lines were split at just over 400 characters, and the incoming lines were just over 440 characters.

Typed into editbox on channel:


Shown in outgoing debug window:


Shown in incoming debug window:


The length of the first incoming message above is just over 440 characters, leaving just 70 characters for anything else the server needs to add to the message. Throw in 20 characters (which is probably conservative) for IRCv3 prefixes, and longer nick!user@hostnames, and we're looking at maybe 40 characters spare on a good day.

Ok, thank you for the demo. I must have misspoke about 300 characters, seeing as the lines that two users were complaining about would have had foreign characters in it. Any chance we could see inside how mIRC's splitting logic works? Curious about how long before you decide to wrap, and without splitting a word or splitting up the bytes of a UTF-8 character?

Somebody told me (more than once) that when a server starts throwing in IRCv3 prefixes, that the client and server must both accept 1024 bytes per command instead of 512. I have not played with any of that, and I don't know what practical meaning it has for PRIVMSG or if it allows one to squeeze more text in.

See my reply to your other post :-]


I have never heard of that but, at the very least, it will need to be something that the client can enable in CAP, otherwise 1024 would break existing clients. mIRC supports a CAP packet-size token (which is not part of IRCv3 but was requested some years ago by someone) and enables it by default to 1024 if the token is available:


However, it has never been extensively tested, as far as I know.

@ Khaled : I believe Raccoon is refering to something I told him but he has misunderstood what I was stating.

@ Raccoon : IRCv3 allows for an additional 512b per message but those 512b are reserved *only* for the message tags. IRC message data, excluding the tags, is still capped at 512 bytes:


- Link

That's an interesting point. This means that a client needs to count IRCv3 @prefixes that it sends separately from the message, so, for example, if mIRC adds IRCv3 prefixes to a line, such as @label=XXXXXX, it needs to count the prefix length separately to the message length.

This also opens up other issues with line splitting. If a line that uses a @prefix is split, the @prefix would likely need to be preserved across each line. In fact, based on the @prefix type, the @prefix itself might need to be modified per split line or even removed.

mIRC does not currently send IRCv3 prefixes but I was planning on using them in the future, so the above will need to be considered.