Custom replacement comment text

[RFBomb]

I figured I would try my hand at putting in the replacement comment text.
I've never worked with rust, and don't know how to compile it (dont have one installed), nor am I very familiar with this branch. But I am familiar with coding in general, and wanted to use that functionality myself in support of the recent API announcement.

I believe the code I threw together should work. Basically I added a variable for it to the config, then used an if statement to assign it to the params. If specified not specified, that expression should default to the lorem ipsam.

Potential Issues:

• I'm not sure how rust will hand a user putting quotes around their new comment string, as the other variables are raw text. I'm hoping that a full block of text could be specified, as long as it is wrapped in quotes, but again, I'm not familiar with how rust handles strings, and its fairly late for me right now.
• After some digging into the code, I cannot for the life of me figure out where the edit() and delete() functions are called from. That boggles my mind a bit, as they are just inside the impl shred block. Anyway, I put another variable in the config to be able to edit the comments without deleting them to preserve displaying the updated comment text. Hopefully that is done correctly.

This is in response to #57

[RFBomb]

After reading #35, the 'edit only' function I threw in there may not be desired, especially if there's inconsistent results or issues going through everything as a result of the API.

Does the API return newest first by default? A diligent user could batch the request themselves in combination with the 'before' flag if so.

[lumirth]

Not sure how much you tested this, but from how you phrased it, it sounds like you haven't tested the edit-only function. I just played around with it a little, and it seems that it fails to not delete the comments. I'd say this PR is likely best without that feature, since @andrewbanchich did in fact say that #35 needs to be solved before edit-only can be implemented.

[RFBomb]

Yea, as I said I don't currently have a rust compiler installed, haven't had a chance to run tests. I was a bit iffy on that 'edit only', especially after I noticed #35.

You said you played with it briefly, did it edit them as expected? And was the not deleting a universal issue, or only when the flag was set true (intended only when flag set true)

[lumirth]

Seemed to edit them correctly(according to flag), but I could be mistaken because I was only seeing the change in between the edit and deletion on Reddit's end. Most of my deletion I just let it use the Lorem Ipsum, which worked as usual. You see, I just happened to sloppily test it while scrubbing an account of mine.

You should see if you can go ahead and grab that Rust compiler. Rust is known for having a well-built and easy to use tool-chain.

[RFBomb]

OK, I got the compiler downloaded, figured out how to build it, and made edits to the PR until it was building fine and no compiler warnings were present.

If you don't mind, I'm contemplating making the output 'pretty' instead of just deserializing the blobs, but I won't touch unless given the say-so.

Heres the format I was thinking:

thing-type: comment
id: -----
permalink:  -------
Source: ------
body: ------------

and maybe remove the config deserialization. (or pretty it up)

[RFBomb]

I just reviewed the API limits, and realized that the PR updates this to stay within the 100/min that goes live on 7/1/23.

The current rate is 60/min, from what I can tell. In my testing, I wasn't rate limited currently, it it may need to be updated if people that they are. But this is now in a constant, so that should be piece of cake.

[andrewbanchich]

Hi @RFBomb , thanks for the CR! Sorry I haven't gotten to it until now (super busy).

I'd like this CR to just include the custom comment text update. Could you remove the rate limit update? It already includes sleeping for 2 seconds per API call. Was that not working properly?

[RFBomb]

Regarding the sleep timer: I'll revert that commit later today.
It was working properly from what I saw.

The reason I asked if it in there was to accommodate the upcoming API changes. Since this is using oath, the rate is changing from 60/min to 100/min. Currently, this tool performs 30/min from what I can tell. So it was a speed-up more than anything. (I saw several comments saying things like it takes a while so I took a peek)

[andrewbanchich]

Ah, I see. Okay, in that case we can change the request rate once the new rate limit takes effect. Thanks for pointing that out!

Still not 100% sure what the implications of the API changes will be for Shreddit (IDK if it will even work at all anymore).

[RFBomb]

I wasn't sure either. But then I took another look at the API changes and the phrasing they used, and I think it will be perfectly safe.

Reason I think that it'll be fine is that the increase in API for OATH accounts was to allow for the continued existence of most bots and tools to exist without needing payment. This fits within that call range.

It also isn't registered to any single user, as part of the setup process is have the shreddit user get their own API token. So each instance of shreddit is effectively a user's personal bot. So it doesn't matter how many people use this, it shouldn't hit the rate limit.

So I believe it will be fine. But only time will tell

[RFBomb]

Alright, I have reverted any changes that are not specifically relevant to the PR topic. I will be issuing a new PR with the rate limit changes.
When this is merged in, I HIGHLY recommend performing a Squash & Merge, as otherwise it will clutter up the commit history of the main branch with the testing and reversions, instead of the much clearer end result.

[andrewbanchich]

@RFBomb Just made one comment. Then you also need to just run cargo fmt and I will merge. Thank you!

[andrewbanchich]

Need to rebase and resolve conflicts.

[andrewbanchich]

Actually, I took care of it 😄

[andrewbanchich]

Thanks so much! I really appreciate it.