Limit issue body to 500 characters

[quanta-kt]

Relevant Issues

Closes #486

Description

This PR puts a limit on how long the response sent by the .hacktoberissues is going to be by limiting the issue body up to it's first 500 characters. This avoids http 400 errors (see #486 ) when dealing with issues with very long body.

Did you:

• Join the Python Discord Community?
• If dependencies have been added or updated, run pipenv lock?
• Lint your code (pipenv run lint)?
• Set the PR to allow edits from contributors?

[ghost]

Thank you for contributing to Python Discord!

Please check out the following documents:

• Join the Discord server! - If you have not already, join the Discord server and introduce yourself in our #dev-contrib channel.
• Python Discord Contributor Wiki - A set of resources about setting up our services
• Python Discord Code of Conduct - Code of conduct for our community
• CONTRIBUTING.md - Guidelines on contributing to this repository

[Akarys42]

Looks good to me, thanks for the contribution!

[Akarys42]

I’m being very picky, but would it be possible to use only 3 dots here? That’s what we usually use.

Suggested change

	embed.description = body[:500] + '....' if len(body) > 500 else body
	embed.description = body[:500] + '...' if len(body) > 500 else body

[Den4200]

You should just use textwrap.shorten instead.

[kwzrd]

What is the motivation for 500? The issue discusses that the embed description can be up to 2048 characters in length.

[quanta-kt]

@kwzrd 500 is just a short number which I think is decent amount characters for embed descriptions. I agree this is opinionated, (large embeds just don't look good to me/I feel it's bad UX). So being pointed out, I'll limit it back to 2048 characters if that's agreeable.

[kwzrd]

It's not necessarily a bad choice, if you think that 500 looks and works better. I was just wondering about why it was chosen. Maybe you could show a screenshot of 500 vs 2048?

[quanta-kt]

@kwzrd Here are the screenshots you requested-
https://ibb.co/M21rqX2
https://ibb.co/gDM642P
The one with 2048 characters totally covers my laptop screen.

[kwzrd]

@quanta-kt Thanks for the examples, I agree that 500 is a more sane value, especially since you can just click the link to read more.

---

@Den4200 @Akarys42 Are you sure that textwrap.shorten is the better choice here? The problem with it is that it removes newlines. Consider this issue, which gets formatted like so:

If we just slice the string, we get to retain the newlines, e.g. this issue:

[Den4200]

Ahh right, I forgot that `textwrap.shorten` removes newlines. Good catch, sorry @quanta-kt.

…

On Tue, Oct 6, 2020 at 3:08 PM kwzrd ***@***.***> wrote: @quanta-kt <https://github.com/quanta-kt> Thanks for the examples, I agree that 500 is a more sane value, especially since you can just click the link to read more. ------------------------------ @Den4200 <https://github.com/Den4200> @Akarys42 <https://github.com/Akarys42> Are you sure that textwrap.shorten is the better choice here? The problem with it is that it removes newlines. Consider this issue <vJechsmayr/PythonAlgorithms#382>, which gets formatted like so: [image: image] <https://user-images.githubusercontent.com/44734341/95248481-a3c81180-0817-11eb-93af-db65a0e07172.png> If we just slice the string, we get to maintain the newlines, e.g. this issue <BitByte-TPC/beginners-byte#3>: [image: image] <https://user-images.githubusercontent.com/44734341/95248661-e853ad00-0817-11eb-8d51-31a5426ba2dc.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMRF7T4OXNYECADS6BOKT63SJNTLLANCNFSM4SGFPGEQ> .

[quanta-kt]

TextWrapper apparently has a replace_whitespace keyword-arg but shorten simply ignores it, weird.

[kwzrd]

Thanks for the contribution, it works great!

Before we merge this, we would be interested in cleaning up the history because there are 5 commits for a 1-line change. In practice, what we would want to do is only keep the first 2 commits, and drop the last 3. This is not your fault, as we told you to make a change and then asked you to revert it.

Are you familiar with git rebase and would you feel confident trying to do this? If not, that's ok, a core dev can help you or do it for you.

[quanta-kt]

Yes I am familiar with rebasing but still a little hesitant to do it, can you check this dummy PR here and confirm if that is how it should be looking like?
Commands used-

git rebase -i issue-486~5 issue-486 # And picking only the first commit
git push origin +issue-486 # A forced push

Also, shouldn't it get squashed into a single commit automatically if one chooses to "Squash and merge" on GitHub?

[kwzrd]

Your dummy PR looks good, but you would want to keep the 2nd commit as well (reducing the dots from 4 to 3).

I think there is an easier way, we actually don't need to rebase because we only need to drop the last 3 commits:

git reset --hard HEAD~3

You can use git log to verify that only commits 5f02c61 and 8645da6 remain. Then git status should say that your local branch is 3 commits behind the remote. Finally git push --force will remove the commits from the remote as well.

Also, shouldn't it get squashed into a single commit automatically if one chooses to "Squash and merge" on GitHub?

Yeah, we had a chat internally and we wanted to give you a chance to do it as it's both a good learning opportunity and also makes sure that the actual commits that get merged are authored by you, rather than the person who squashed them.

[kwzrd]

Lovely, thank you!