Skip to content
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

Message edits are incapable of triggering commands #18

Open
yellowtides opened this issue Mar 8, 2021 · 3 comments
Open

Message edits are incapable of triggering commands #18

yellowtides opened this issue Mar 8, 2021 · 3 comments
Labels
enhancement New feature or request low prio

Comments

@yellowtides
Copy link
Owner

Current functionality

MessageCreate m ->
unless (isFromBot m) $ (forM_ messageReceivers ($ m)) <|> pure ()

As can be seen in the above highlighted lines of code, commands can currently only get triggered by creating a new message.

Reasoning

Message edits are not capable of triggering commands. It would be a nice addition if they would also get processed on message edits, as our : prefix makes Discord emoji autocompletion typos quite common.

(e.g. :fortune → 🥠 | :fortune:)

Potential solution

Pattern match on the MessageUpdate Message Event data constructor in order to also detect message edits. Further modularise the message creation event handler into its own function, which should be triggered on both event sub-types.

E.g.

handleEvent event = case event of
     MessageCreate m -> 
          consultReceiversOnHumanMessage m
     MessageUpdate m -> 
          consultReceiversOnHumanMessage m
     -- // SOME LINES REDACTED  FOR VISIBILITY //
     where
          consultReceiversOnHumanMessage m = unless (isFromBot m) $ consultMessageReceivers m
          consultMessageReceivers m = forM_ messageReceivers ($ m) <|> pure ()
@social-anthrax
Copy link
Collaborator

Could be useful, however, most bots do not implement this even if it is supported by the module. This is to stop the bot from going back through messages and replying multiple times due to the user fixing a spelling mistake. It's normally safer to just let the user send another command.

@jacobjwalters
Copy link
Collaborator

Some bots (e.g. MathBot) do track edits, but these often take large inputs (such as entire TeX expressions or the likes). Since the majority of owen's commands are only two words long, I don't think it's (currently) a high priority at all.

@social-anthrax social-anthrax added wontfix This will not be worked on enhancement New feature or request labels Mar 14, 2021
@social-anthrax social-anthrax added this to Ideas in the cloud in General Development via automation Mar 14, 2021
@social-anthrax social-anthrax moved this from Ideas in the cloud to Discarded Things (unfeasible) in General Development Mar 14, 2021
@social-anthrax social-anthrax moved this from Discarded Things (unfeasible) to Ideas in the cloud in General Development Mar 14, 2021
@yellowtides
Copy link
Owner Author

Fully agreed @9nine9nine9, as this would also require a messageID -> [replyID] mapping that Owen could use in order to clean up replies after every message edit. I will change this to low priority.

@yellowtides yellowtides added low prio and removed wontfix This will not be worked on labels Mar 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request low prio
Projects
General Development
  
Ideas in the cloud
Development

No branches or pull requests

3 participants