Traceback "more" enhancements

[RheingoldRiver]

What component of Red (cog, command, API) would you like to see improvements on?

traceback

Describe the enhancement you're suggesting.

Right now, the default UX feels pretty clunky. The feature I proposed was to stop messages from flooding the chat, and it's certainly doing that, but it's also stopping the user from gracefully seeing all messages at once. I'd propose the following enhancements:

1. Change the default number of pages to 2 at a time instead of 1
2. Add a keyword response all
3. Tell the user where they can go to configure the number of pages at a time in the response. The language could be:

   There are still {} messages remaining. Type `more` to continue, `all` to finish, or `file` to upload all contents as a file. Change pagination volume with `[p]set tracebackpagination`.

   Of course, replace my fake command with the actual command that changes 2 to the user-set pagination volume.

Anything else?

I really appreciate that you take the time to implement my UX suggestions, and I feel really bad that this one didn't turn out great in its first implementation. I think with these improvements it'll be a much better experience though.

[RheingoldRiver]

Edited, I think "volume" is a better word than "speed" for the size of each payload

[Flame442]

I believe traceback is currently just using the Context.send_interactive helper Red provides. This helper is intended to be used in cases where the bot explicitly should not be sending all of its messages back to back, as that would lead to API spam. For that reason, I don't think all will be added as an option for sending the remaining N messages all at once as messages.

As for allowing the number of pages sent at a time to be configured (and potentially changing the default of that setting to 2), currently there are 2 send events (the actual content + the "There are still x messages remaining" message) and 1 delete event happening every time more is said, and increasing that (or allowing it to be increased) would be getting very close to API spam. Additionally, it would be a setting that affects all cases of send_interactive, and I'm not sure how that would affect non-traceback parts of the codebase.

There is currently the file option (added with #5902 in 3.5) which outputs all of the remaining content as a file. On some platforms, the file can be previewed from within discord, however there are some platforms where the file would have to be downloaded and inspected. This is the best workaround Discord provides for sending bulk amounts of data.

[RheingoldRiver]

For that reason, I don't think all will be added as an option for sending the remaining N messages all at once as messages.

Wouldn't it make sense for send_interactive to always offer all ? I suggested it for traceback specifically because that's the one that I use the most, but I can't imagine that ever being an unwanted option any time there's a send_interactive response.

Regarding the number of messages change, that makes sense, although one option could be to clamp the length of the most recent message a bit and include "type more to see more" in the body of the last message sent. It would add a bit of complexity but if that allows you to get up to say 3 messages at once instead of 1 (so config is just 1-3) it would help UX a lot imo.

[Flame442]

While I can understand the user experience reasoning for adding either of these two features, I'm not sure if the API is really built for either to be a good option. While I'm not ruling out accepting either of them, I personally don't think the benefit to users outweighs the fact that they allow users to override the cog creator's intention of using this method to prevent API spam, somewhat degrading the method's purpose.