It'd be kinder to mobile users (whose keyboards often insert a space after every word when autocompleting) if trailing whitespace at the end of <3 nick and </3 nick was ignored.

Issue noted when IRC user DHMO was mobile.

It's typically associated with "karma" functions, but being able to nick++ and nick-- would be neat, I think.

Considerations would be:

• avoiding conflict with other known modules that use this syntax
• deciding whether to trigger only on whole-line matches (like the ACTION handler for <3 / </3) or allow nick++/nick-- in the middle of a line to work
• silently ignoring nicks that don't exist (should be trivial because <3s already do this)

Added in sopel 6.2.1, so obviously depends on #2 (my bot's running 6.x since about a week ago).

Using trigger.time means rate-limiting will use the value of server-time if available. No real change, but should make the rate limit more accurate (not that anyone ever complains about it being off by a second or two).

Have separate timers for luv & h8, with luv being shorter so it's easier to spread love than hate.

Idea submitted on IRC by @vil33.

[23:37:16] <vil> need to decrease love timer in the future
[23:37:24] <vil> so love can spread faster~

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.

Need a way to output the top n (and also bottom n?) users by rep score. Ideally, without having to switch away from using bot.db for storage…

Discovered when someone did .luv dgw\ as a joke/typo (not sure which tbh) and it actually increased the rep for dgw (me).

Probably a nick verifier glitch. I suspect something is improperly escaped in a regex somewhere, especially since the <3/</3 and ++/-- commands don't even register if the nick passed contains \.

Can either steal this code from my AniTV plugin, or push this off a few more months until Sopel 7 is finished (I've been thinking about it for years, after all) and use the upcoming seconds_to_human() utility function. Either is fine, really. The new Sopel tool formats its output in a way that might not be quite what this plugin wants, if I think about it too much.

Now that the module is updated for Sopel, and Sopel supports third-party modules installable via pip, this one should be published in the repository.

Decision: cookiecutter modules actually reside in the sopel_modules/modname/modname.py file within the git repository. It's probably possible to rewrite the module history to look like it's always been there—and therefore preserve git-blame-ability—but is that worth doing? Probably not. It could mess up Github's Contributions calendar, and would certainly mess up any commit hashes that are referenced in issue/PR histories.

1. privileges don't exist in PMs, so this eliminates a bug
2. rep should only be modifiable in public—in channels—anyway

Brought up by WZ1 on IRC. Similar type of abuse to #6 but a different approach, and thus needs to be combated differently.

No-brainer really. They've been hard-coded in the source for too long already.

The "karma" commands (added in #20) are interpreted even if the input line starts with a rep module command. It results in processing the same line twice.

Title. Need to rework r_nick (below) so it will skip triggering on even more invalid nicks.

If a line looks like, for example, dgw++ Bucket++, and dgw is not in the channel, nothing will happen. The module only matches the first karma command in the line, and then it stops.

Looping through all karma commands in a matching line would allow users to be more lazy about checking whether the person(s) they want to .luv/.h8 are online, by mentioning multiple nicknames at once and letting the module figure out who's online.

Requested feature; I'm just making the ticket.

Should be pretty simple to do based on hostmask matching.

Possible criteria to use for blocking (in combinations or alone):

• same ident as target (ignoring ~)
• same hostname as target
• nick contains significant portion of target's name
  • more generically, a similar nick based on some sort of string similarity algorithm score
  • yes, this would need research, and probably an additional dependency
• nick has never been seen before (has no rep_ keys stored in the DB)
  • this would be especially useful as a weight factor for other criteria

OP to be updated as I think of ideas.

e.g. .LUV NICKNAME fails with the "Logic error!" message that's never supposed to be output.

Already found where this is going wrong, and a fix is in testing on a feature branch right now.

No matter which command type is used, if an attempt is made to luv/h8 someone who is not in the channel, the module always says "You can only luv/h8 someone who is here".

It'd be nice if it used the same command type as the user did, e.g. "You can only <3 someone who is here" or "You can only ++ someone who is here".

(Original idea from @Yuuki2012 via IRC.)

BombBot checks more than just nickname equivalence when deciding if someone is trying to self-bomb. rep should perform similar checks (whether nicks are grouped, etc.)

If verified_nick() finds no valid nickname, it returns None currently. That's no issue in sopel-rep itself, but it breaks in prototype code for dgw/sopel-duel#36 because comparing Sopel Identifier objects using == is overloaded in Sopel code; it tries to access the nonexistent property NoneType.lower.

Returning empty string maintains the false-y return value while avoiding this issue without getting into try/except or extra if conditions.

Instead of @module.rule, once Sopel 7.1 goes stable this can use @plugin.search instead. That will eliminate the need for .* around the pattern and make things more sensible (since the new decorator always matches the first occurrence of its pattern in the line).

Probably due to missing conversion to Identifier objects before manipulating nicks with .lower() and looking for them in bot.privileges elements.

>>> from sopel.tools import Identifier
>>> s = 'Kaitou^'
>>> i = Identifier('Kaitou^')
>>> s.lower()
'kaitou^'
>>> i.lower()
u'kaitou~'

Lots of "if available" features these days.

Sopel 6.2.0 deprecated the bot.privileges dict. It was replaced by bot.channels, which contains more state information. Obviously this depends on #2 (but should not block it—see below).

As of 6.3.0 the bot.channels dict doesn't seem to be populated quite correctly, but when it's stabilized and can replace bot.privileges it should be used if available, as the deprecated API will probably disappear in 7.x (or by 8.x at the latest).

At some point, abandon old versions of willie and make this a sopel module. Including renaming it (shock!).

My bot runs 6.3.0 right now, so it's only a matter of time. Short time.

Due to how Python handles floating point numbers when interpolated into strings, the remaining seconds are truncated at the decimal point (not rounded). This can lead to the user being told to wait 0 more seconds before changing rep again, when the remaining time is below one second.

Timer code should round the value up to the next integer for display, so even if there's less than a second left it still appears as "1 second".