scarletcafe / jishaku

A debugging and testing cog for discord.py rewrite bots.
https://jishaku.readthedocs.io/en/latest/
MIT License
541 stars 181 forks source link

Using "jsk debug" with application commands #185

Open seriaati opened 2 years ago

seriaati commented 2 years ago

The Problem

Currently, when I try to use the jsk debug command with an application command, jishaku tells me that the command is not found. For example, I want to debug a command called /check I've tried doing jsk debug check and jsk debug /check, both returned the same result: Command "/check" is not found

The Ideal Solution

The ideal solution would be to be able to debug slash commands by doing jsk debug /<command_name>

The Current Solution

I don't think there is any solution right now.

Summary

For jsk debug to support slash commands/application commands

scarletcafe commented 1 year ago

The main issue with implementing this at the moment is trying to cross the bridge between text and slash commands. The latter has frontend-bound delimitation between arguments which sort of gives it an advantage when dealing with argument parsing - even if I were to try and hook into normal command parsing and forward it to slash commands, it still wouldn't be able to deal with the fact that e.g. slash commands could effortlessly have """"" as a valid argument.

Ultimately I probably will figure out a compromise and do this. I'm just not sure about how to do it justice yet.

seriaati commented 1 year ago

thank you for your reply, I look forward to the new feature!

skylarr1227 commented 1 year ago

why not have a separated debug entirely-one for app_commands, and one for command.commands. Seems logical to me, and with app_commands would likely even be able to debug other app_command based ui items to.

scarletcafe commented 1 year ago

The issue is less whether it should be part of the commands ext jsk debug or not (it probably shouldn't) but rather that Discord is the end with the responsibility of argument delimitation for slash commands, and the client's slate UI allows for disambiguation and validation that's usually not as easily possible otherwise.

Unlike the slash commands themselves, I can't prevent you from sending a combination of arguments that makes no sense, or is of the wrong type, or etc. Commands ext has technically always had such a problem and that's why converters exist, but they're not a perfect one-to-one for slash commands. I also can't easily deal with situations where e.g. the user selects and sends a returned autofill entry - in this case, what the UI displays and what is actually sent does not even match.

None of this makes it not doable, it's just that a difficult-to-use feature is about as useful as a non-existent one, and if you're having to go and pull up docs and cross-check with the original command every time you want to try and use the command I'd figure more people would be willing to just use jsk py to call their callbacks directly, and at that point the feature has failed to do its job.