-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved handling of mode changes in buffextras.lua #14
base: master
Are you sure you want to change the base?
Conversation
Should probably check |
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 |
…ras.lua This should now pretty much emulate what HexChat does normally. I haven't yet tested it enough for full confidence though.
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. |
…nmodes'] in buffextras.lua
@someperson BTW the chanmodes property landed and has been out in a release for a few weeks. |
HexChat/buffextras.lua
Outdated
@@ -1,10 +1,6 @@ | |||
-- SPDX-License-Identifier: MIT | |||
--- SPDX-License-Identifier: MIT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this change? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops. Will fix.
HexChat/buffextras.lua
Outdated
else | ||
emit('Kick', nick, word[6], channel, word_eol[9]) | ||
nickmodes = hexchat.props['nickmodes'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be local
, same with others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. Will fix.
What about using the |
In theory. It also may cause unwanted side-effects but I've not looked into it. |
Needs rebased. |
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