Linesplitting flaw
Closed this issue · 3 comments
When splitting lines, Dirk does this with respect to the client sent string, but the server itself also has to send the PRIVMSGs back with the maximum of 510 chars. Unfortunately, the server additionally sends the userhost (e.g. Doeme!~Doeme@127.0.0.1), so the strings sometimes get cut off anyways.
I looked into the IRSSI-source and they solved it by just subtracting an additional constant(they made an educated guess that it would be a maximum of 74 chars).
I took the liberty and applied the change to a fork:
Doeme@c92ec09
Hm, we can get the specific hostname with the USERHOST command, but the hostname could change at any time without notification, such as when a user applies a virtual hostname, so I guess the conservative estimate is the only solution. Do you want to file a pull request?
Hm, one could also periodically poll the userhost, but I don't know wether this is that much better than just the constant.
I also looked it up in XChat (HeXChat, as a matter of fact), and they do use the hostname, if they can get it. Otherwise, they just use the same constant as IRSSI.
KVIRC also uses the hostname, but without the fallback.
https://github.com/hexchat/hexchat/blob/master/src/common/outbound.c#L2574
https://github.com/irssi/irssi/blob/master/src/irc/core/irc-servers.c#L201
https://github.com/kvirc/KVIrc/blob/master/src/kvirc/ui/KviChannelWindow.cpp#L1189
At the end of the day, it's your project, I just implemented a quick fix for my instance, which is kind of ugly, because the server-side limit does not apply to all the commands, only the ones where the server responds with the text.
But if you want me to make the pull request, I'll gladly do it.
OK, sorry for the delay.
The result of the USERHOST-command is unreliable, because of hostnamecloaking et al.
For example, on rizon.net the USERHOST-command returns Doeme+=Doeme@255.255.255.255,
whilst the hostname in the PRIVMSG-field is the cloaked string Doeme@Rizon-525492651.some.host.name
Concerning the command-classification, I made an attempt by having an enum holding all the additional lengths and subtracting them if necessary (See Doeme@108a048)
I feel like this somehow mature enough for a pull request, so I'm going to submit one shortly.