Sopel 7.x added support for accessing the network's 005 RPL_ISUPPORT parameters from plugins. One of those is NICKLEN, which lets the server specify a maximum nickname length that may be different from the IRC standard.
Ideally, sopel-rep would just yoink that value and use it in @rule (and/or @search after #36 is implemented) patterns, but those get loaded before Sopel even tries to connect to IRC. Once the bot is connected and has the ISUPPORT values available, it's too late to use them in rule patterns.
It's possible to screw around with the bot's rules during runtime, under the rewritten system implemented for Sopel 7.1. One could unregister a plugin (which removes all of its rules) from the rule manager, then add back the "real" rules, but it's a kludge at best.
No help from the new-to-7.1 *_lazy rule decorators, since they only get the bot's settings. sopel.config.Config objects don't contain any pointer/reference to the Sopel instance that owns them, so it's not possible to get at the ISUPPORT params that way either. Which is unfortunate, since a "lazy" rule sounds like the perfect thing to use runtime state, but that's a whole other discussion I'd have to have with other Sopel maintainers.
tl;dr: This isn't really possible yet, but I want to keep it on the radar.
Sopel 7.x added support for accessing the network's 005
RPL_ISUPPORTparameters from plugins. One of those isNICKLEN, which lets the server specify a maximum nickname length that may be different from the IRC standard.Ideally, sopel-rep would just yoink that value and use it in
@rule(and/or@searchafter #36 is implemented) patterns, but those get loaded before Sopel even tries to connect to IRC. Once the bot is connected and has theISUPPORTvalues available, it's too late to use them in rule patterns.It's possible to screw around with the bot's rules during runtime, under the rewritten system implemented for Sopel 7.1. One could unregister a plugin (which removes all of its rules) from the rule manager, then add back the "real" rules, but it's a kludge at best.
No help from the new-to-7.1
*_lazyrule decorators, since they only get the bot'ssettings.sopel.config.Configobjects don't contain any pointer/reference to theSopelinstance that owns them, so it's not possible to get at theISUPPORTparams that way either. Which is unfortunate, since a "lazy" rule sounds like the perfect thing to use runtime state, but that's a whole other discussion I'd have to have with other Sopel maintainers.tl;dr: This isn't really possible yet, but I want to keep it on the radar.