But no, 80-column terminals in 2020 isn't “reasonable” any more

I mainly use Clojure and keep most of my lines under 80 characters.

I try to keep my Clojure code under 80 characters (so that I can have three editors comfortably side by side at my preferred font size) and keeping lines short is more than just where to wrap or other visual-only things. Usually when I have a long line, it makes me reconsider the structure of the code and I refactor it into something else. Most of the time, the new structure not only has shorter lines, but is simpler too, so its a double win. This isn’t always a task that the tools could do for mem, though, as it sometimes rewuires rethinking what I’m trying to accomplish.

No matter what I say here, I feel it would be very likely you will tell me I'm wrong.

> that process is obsolete, cumbersome, finicky and convoluted.

It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it.

Here's what I don't like about Github

1. You need to set up an account on there (I already have an email account)

2. You need to fork a repo rather than just simply cloning it.

This means you have to go through a rather convoluted process to keep your fork up to date with the original repo. That either involves setting up another origin pointing to the original repo and then pushing up those changes to your forked repo (and taking into account any branches you updated). Or you have to delete the forked repo, fork it again and then have to somehow resolve possible conflicts when running git pull.

3. It's not possible to comment on a commit message itself

This means that I need to comment on the first line of the diff for that commit or I have to edit the url to navigate to the commit itself and then type stuff into a comment box at the very bottom of the diff.

Then that comment doesn't show up with any context other than saying "github-user commented on abcdef1". And those comments disappear when someone force pushes to the branch to update the commit. If the comment is associated with the first line of the diff for that commit, it either is collapsed or not depending on whether the line changed. I still have to go to the commit view to check whether the updated commit message addresses my comment.

4. It collapses comment threads when the line of code changes regardless of whether the change pertains to the original comment.

This means I have to scroll from the top of the conversation view page and search for collapsed comment threads to find the comment I made, then go to the diff view to compare that line with what's in the current diff to determine whether the change actually addresses a comment I made

5. It's not easy to jump between different revisions of the branch over several force pushes in a way that makes it easy for me to see what changed on a per commit basis

6. It doesn't provide a way to distinguish different subthreads of conversations on the same block of code

7. It requires far more scrolling in the conversation view when there are a lot of comments on a pull request

As for email, all I need to do is

1. Run a few git config commands to set up git to send email using my existing email account (this is a one type step)

git config --global --add sendEmail.smtpServer "your.server"

git config --global --add sendEmail.smtpServerPort 587

git config --global --add sendEmail.smtpEncryption tls

git config --global --add sendEmail.smtpUser "your.email.username"

2. Clone their repo, check out the appropriate branch, make your own branch and do your work

If the upstream repo is updated while you do you work, you can simply run git fetch and rebase your local branch on top of the updated branch, which is a lot less convoluted compared to what you have to do to keep a Github forked repo up to date.

3. Create your patch files with cover letter

git format-patch --to email.list.address --cover-letter base-branch

4. Edit the cover letter file and update the subject and body to include your patch series description (which isn't much different than composing the PR description on Github)

5. Run git-send-email to send your patch series to the email list

git-send-email *.patch

6. Check your email for replies, engage in addition discussion, etc (which is better than having to scroll through a large diff to find every comment)

7. Update your code, rebase

8. Run git format-patch the same way but add -v2 to indicate a reroll

9. Run git-send-email and reference the message-id of the original cover letter

In terms of engaging in discussion over email, one can reply inline and comment on any part of the cover letter, commit message, line in the patch etc. One can save the emails from multiple patch series, run git am to apply them in different branches locally and run git diff or git range-diff to check what's changed. That's not possible in Github if someone force pushes to the branch because there's no longer a remote branch to fetch to allow for a comparison.

In any case, I would certainly be interested to read your specific complaints about the email based process instead of just a dismissive reply.

I am skeptical but curious. I honestly can't think of one. The closest one I can think is maybe you have some kind of macro that uses a temp variable? like a swap macro? But i think you can still have a unique variable name for that particular line if you want?

But if these cases are exceptional then you can use pragma to suppress those warnings for that particular block of code. If they are not exceptional perhaps you shouldn't have enable the warning/linter check for that warning.

But honestly I can't think a good reason for shadowing variables and would appreciate an example