plugins
plugins copied to clipboard
TingPing
Improved handling of mode changes in buffextras.lua
I made some changes to buffextras.lua to try to improve the handling of mode changes.
Here's what HexChat normally displays for some activity in a channel:
And here is what buffextras turns this into in ZNC 1.6.3:
The original buffextras.lua doesn't quite handle the mode changes properly. The mode changes from the server are unreadable, and the changes from the user clearly have a different format from what is normally used:
After my changes, this is the result:
It's not perfect. Obviously, HexChat normally does some parsing of the mode changes and even breaks them apart so that it can display a nice message for particular changes (e.g. +b or +l). This is not implemented here, but I think it's at least an improvement.
Thanks for considering this change!
Sam
Should probably check hexchat.prefs['irc_raw_modes'] also, if enabled use previous behavior.
Thanks, I didn't know that preference existed. I just changed it so that it will use "Raw Modes" or "Channel Mode Generic" based on how it is set. Also cleaned it up a bit to avoid duplicate code.
Your usage of Channel Mode Generic also seems wrong. It takes 4 args: nick, mode sign (+/-), mode letter, channel. You seem to combine the last three into one.
Also if you want to match HexChat behavior exactly we will have to expand this quite a bit. It parses specific letters into specific events like Channel Ban and falls back to Channel Mode Generic: https://github.com/hexchat/hexchat/blob/master/src/common/modes.c#L438-L572
Also when there are multiple modes (I don't know how znc handles this?) there is a different event Channel Modes.
You can see why I took the lazy route of Raw Modes :P
I've now implemented support for the specific events. The modes are now also therefore split apart and sent separately, like HexChat does normally. I added a hook for 005, as you suggested would be possible, in order to retrieve the CHANMODES parameter, which affects parsing of arguments.
The "Channel Modes" event seems to only be used when the user requests the modes for a channel by way of '/modes #channel'. This is not logged by buffextras, and doesn't represent a change of any sort, so I didn't bother implementing it.
In theory, this should now pretty much emulate HexChat's normal behavior, though I haven't done much testing with it yet. I'd appreciate a second set of eyes on it.
@someperson BTW the chanmodes property landed and has been out in a release for a few weeks.
What about using the RECV command and have Hexchat do its normal handling instead? Can that also parse tags (so we can fix the timestamps of mode setting)?
What about using the RECV command and have Hexchat do its normal handling instead? Can that also parse tags (so we can fix the timestamps of mode setting)?
In theory. It also may cause unwanted side-effects but I've not looked into it.