Cog-Creators
Support edited command calls to reinvoke themselves
Type of feature request
Command
Description of the feature you're suggesting
- Just a simple toggle [p]onedit with a subcommand to set the timeout
- Users make typos as humans, and on edit if red was able to reinvoke command by itself, it would be nice
- Similar to how a 3rdparty cog (OnEdit by zeph) does it.
- I'm not exactly sure where to put it but Core likely
- Tho Red is all about extensibility, I would rather see this in core, as it is pretty much common among every bot I come across.
- It gives better UX as well.
Anything else?
Maybe not, This was previously brought up by draper in #4401 but then was suppressed all of a sudden, hence opening it back.
Something worth noting if this feature gets merged into core - using bot.process_commands directly will create another instance of dispatching on_message_without_command, which is undesirable in most every case (cog creators and core cogs don't expect edited messages to show up in said event). See zephyrkul/FluffyCogs#15 for more details - my cog essentially re-implements process_commands without calling the event. Presumably, if this feature is merged into core, a simple if message.edited_at: could be used before the dispatch call.
Instead, my cog maintains a whitelist of core and approved cogs that emulate commands using on_message_without_command and calls the listeners for those cogs directly. If this functionality enters core, it'll now be up to the maintainers of Red to maintain such a whitelist, or to abandon the idea of such a whitelist entirely at the cost of usability to end users of Red bots.
Implementing this may also require implementing an on_message_edit_without_command or similar, for the same reasons that on_message_without_command exists.
This is not something we are going to add into core ATM. As there is already a 3rd party cog that handles this well, I don't feel like there is a need to pursue this.
Instead, my cog maintains a whitelist of core and approved cogs that emulate commands using on_message_without_command and calls the listeners for those cogs directly.
A small addendum to this: by correctly implementing an event such as on_message_edit_without_command, it's possible to avoid the need to maintain such a list, and offload the work of such to each cog instead.
This is not something we are going to add into core ATM. As there is already a 3rd party cog that handles this well, I don't feel like there is a need to pursue this.
I've initially been against merging this functionality into core due to that cog alredy existing, but after maintaining said cog for some time, I can say that there are two downsides to it being 3rd party that I've seen. If the core team considers these to be minor downsides, then I have no issue continuing to keep the cog as 3rd party, but I wanted to bring these up for consideration regardless.
The first, and minor, downside is the fact that creating such functionality implies that on_message_edit_without_command needs to exist. As it happens, my cog already does this, but as it's an undocumented event that only exists in a 3rd party cog, no cogs implement said event.
on_raw_message_edit_without_command would likely also need to be implemented. onedit doesn't currently do this due to on_message_edit_without_command not being adopted by the wider 3rd party cog creator community, but it is possible for me to implement such an event if needed.
The other downside, and slightly more important but still a bit of an edge case, is that most cogs that implement on_message_edit or on_raw_message_edit do so without first checking if said message edit would trigger a command. Currently the only way to check that is to implement both the normal event and the _without_command event and check for the existence of bot.get_cog("OnEdit") in the normal event, since it's impossible for the _without_command events to trigger without the cog. Moving onedit's functionality to core would make it so creators would only have to implement the _without_command event, as core Red could dispatch said event even when the functionality isn't active.
Workarounds exist for both of these downsides, but the most effective solution remains to merge onedit's functionality into core. If the core team decides to go through with this solution, I am willing to file a pull request to make it happen. If not, onedit will remain available as a 3rd party cog.