[fao_]

> Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.

Use three terminals? No, seriously, you can pack even more information into the screen than you already do, which was already presumably your intent when you switched to the font. Wouldn't that be the logical end-limit here? After all, most tools still standardize around 80 characters, most terminals on GUI machines start up for the first time with 24 rows and 80 columns. It seems like you're arguing against an unnecessary standard.

Hell, wouldn't the proper solution here be to add a flag or a config file to the analyzer to alter the defaults, rather than. This is already a solved problem for code analyzers in general, most C linters (including clint) support these flags.

[yebyen]

I'm actually not arguing to change the default, I'm arguing that the team should have a conversation and decide on whether the default is reasonable for them. I'm not using a narrow width font because I want to pack more information on the screen, in fact I'm using it because it's more readable, at any size (small or large.)

I actually hope that when I have this conversation with my team, someone looks at my screen and says "hey, that is a nice font, and more readable than what I've been using."

[pizza234]

> After all, most tools still standardize around 80 characters

I use standard Linux tools for development, and none of the tools themselves have any column standard. Probably text-only emails are the only thing that have a "standard" of 80 columns.

> most terminals on GUI machines start up for the first time with 24 rows and 80 columns

This doesn't really mean anything. I don't think there's anybody who leaves the terminal as it is, as even on a modest 1080, that'd be one quarter of the screen area.