provide feedback when an unknown command is entered

[nhooyr]

Kinda related to #34

Sometimes a user typos on a command or whatever but my bot stays silent when this happens. If an unknown message is received with a command prefix, I want to be able to notify the user that they typoed a command or whatever and show them the help.

[cronokirby]

Just write a message event handler for this, as discussed previously.

[nhooyr]

But there is no interface for me to access the current list of commands, I'd have to maintain it manually or it would have to be exposed.

Why can't we just add a new Cogs.set_fallback(mod, func) function? You said you didn't like it but never explained why.

[cronokirby]

I feel like Cogs.set_fallback has a limited use case, but a function to get a list of commands has a much broader one. Since a command list method would be a lot more useful, and also satisfy that use case easily, I feel like that should be what we should implement instead:

Events.on_message(:cmd_help)
def cmd_help(%{content: @prefix <> rest} = message) do
  [cmd, rest] = String.split(rest, " ", parts: 2)
  with nil <- Cogs.all_commands()[cmd] do
    Cogs.say "That doesn't look like a command"
  end
end

[nhooyr]

What if the message matches a command, but does not match the arguments for the command? Then I would not be able to know and provide user feedback.

[cronokirby]

You can handle such cases already:

Cogs.def args2(a, b) do
end
Cogs.def args2(a) do
end
Cogs.def args2 do
end

[nhooyr]

Ah, I guess its fine then. My only issue with Cogs.all_commands(mod) is that it feels unclean for me to check myself, when I know that the it is already also being checked internally.

Its no performance issue by any means and I agree that it does solve my issue and more, but I think Cogs.set_fallback would be the optimal solution and Cogs.all_commands(mod) would used for different purposes.

But its your project so your call. I can work on a PR for either.

[cronokirby]

https://github.com/cronokirby/alchemy/commit/af5326f40f589e7d36977454c189feaa961ad7dc solves this. We should possibly revisit this when we work on making the lib as a whole more configurable.