taxon: reaction-triggered predicates should not respond to commands

[synrg]

[9:19 AM] SyntheticBee: Suppose I have a general on_reaction_add handler that looks for reactions to specific embeds and then prompts the user with a predicate to add information to that embed. Now, suppose the user types a command instead of a response to the predicate ... both the predicate and the command are now triggered. What provision should I make for this? [9:21 AM] SyntheticBee: Let's further suppose that by some freak accident (or deliberate attempt to see what would happen), and the predicate is actually asking for a username, and the username happens to start with the bot's prefix and a valid command for the bot. Now, enclosing the username with double quotes should work to achieve the desired behaviour here, but let's say they don't know that. So now both the command executes and the predicate has been given valid input. [9:22 AM] Sinbad Apple: on_message_without_command exists if you want to ignore command messages while looking at messages. [9:22 AM] SyntheticBee: So that would enclose the predicate dialog. [9:23 AM] SyntheticBee: or ... ? hmm. i'll look this up instead of guessing. :) [9:23 AM] Sinbad Apple: And if you track which users you are currently interacting with prior to processing them, you avoid the "2 seperate interactions" bit [9:26 AM] SyntheticBee: K. I'll file an issue to tighten that all up following this approach. Thanks.

[synrg]

A few other things to look into:

• confirm only a single message entered by the user who pressed the button is matched, looked up, & deleted (i.e. should not consider messages typed by anyone else during the 15 second waiting period)
• provide a way to cancel the lookup (a second press of the same button should suffice)
• ensure sufficient time is given for the user to see a failed lookup message before that message is removed

[synrg]

b7d364186d3831b5a747c081497960824008f1e7 solves half of this (single-threading user reactions & predicate prompts) but I don't think on_message_without_command actually helps here, as it is already inside on_raw_message_add or on_raw_message_remove when the predicate is fired.

The recently added config.guild.bot_prefixes plus the bot's own prefixes could be matched against the start of the response and then the response should be ignored if any match.

[synrg]

Fixed in 8df5ebe66b4cc9b8b6cd0fa3eba5527a86a71d0c