question: remove 80 char line limit?

Can we increase the limit to something like 95-100 or remove the strict limit from linting? Seems archaic to have such a limit with higher resolution screens these days. Just my $0.02

I don't have a strong opinion on this and would like to hear more opinions.

Because stuff like this and this just upsets me, especially when concatenation is happening at runtime possibly for every api call.

When I first started wrangling with the 80 limit, I felt the same way. I eventually figured out it can be annoying (for sure), but has also lead to some better clarity/maintainability decisions, I think.

The links you pasted used to bug the heck out of me, but I'm over it.

However... I would be totally willing to extend the limit, if we weren't already so far along with 80 characters. What would look worse to me is a bunch of 80 char limits mixed in with not as strict limits. And going through the code and sending a 100% line diff PR would be pretty nasty... For these reasons, my vote is to stick with 80.

(Side note: My 15" MBP retina barely fits 2 side-by-side 80char windows with only a little room left off to the side for the terminal to be visible).

if we weren't already so far along with 80 characters

I mean the library isn't that big.

100% line diff PR would be pretty nasty

Only lines that could really benefit would be affected, but yes there would be some mix.

barely fits 2 side-by-side 80char windows

Yeah, I don't look at multiple files simultaneously very often but if I do, I could always shrink the text to fit. Guess this is a "my use case vs. your use case" situation.

That being said, I don't hold this idea too close to my heart, just curious why the 80 char value was chosen in the first place for this project E.g. "it was a default value in the config" or "I've always done it this way... just seemed right" or "because 80 chars was the column limit for punch cards back in 1928"

I think regardless of the long history of "why 80", the less characters you can use to write a line of text, the easier it becomes to follow along. 80 is a standard that works well. Having multiple windows open is a pretty common use case in code, which is why narrower lines really help. Again, I'm not tied to 80, but I stand by it being more helpful than limiting. My only reason for not bumping up the limit is for the reasons I said before. I would personally find it really offputting to have hard 80 limits mixed with a wider one (in addition to the code, all the docs are at 80). However, if a pr covered all of it, I would +1 it :)

I'm going to add my vote for keeping the 80-char limit. I'm in the boat of people who do side-by-side file editing, and would rather not have to shrink text...