Hi Linus, On 5/29/20 9:19 PM, Linus Torvalds wrote: > On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@xxxxxxxxxx> wrote: >> >> A wide monitor is for looking at lots of files. > > Not necessarily. > > Excessive line breaks are BAD. They cause real and every-day problems. > > They cause problems for things like "grep" both in the patterns and in > the output, since grep (and a lot of other very basic unix utilities) > is fundamentally line-based. > > So the fact is, many of us have long long since skipped the whole > "80-column terminal" model, for the same reason that we have many more > lines than 25 lines visible at a time. > > And honestly, I don't want to see patches that make the kernel reading > experience worse for me and likely for the vast majority of people, > based on the argument that some odd people have small terminal > windows. > > If you or Christoph have 80 character lines, you'll get possibly ugly > wrapped output. Tough. That's _your_ choice. Your hardware limitations > shouldn't be a pain for the rest of us. Unfortunately refreshable braille displays have that "hardware limitations". 80 cells displays are very expensive. Visual impairments is rarely a "choice". Relaxing the 80-char limit make it harder for blind developers to contribute. > Longer lines are fundamentally useful. My monitor is not only a lot > wider than it is tall, my fonts are universally narrower than they are > tall. Long lines are natural. > > When I tile my terminal windows on my display, I can have 6 terminals > visible at one time, and that's because I have them three wide. And I > could still fit 80% of a fourth one side-by-side. > > And guess what? That's with my default "100x50" terminal window (go to > your gnome terminal settings, you'll find that the 80x25 thing is just > an initial default that you can change), not with some 80x25 one. And > that's with a font that has anti-aliasing and isn't some pixelated > mess. > > And most of my terminals actually end up being dragged wider and > taller than that. I checked, and my main one is 142x76 characters > right now, because it turns out that wider (and taller) terminals are > useful not just for source code. > > Have you looked at "ps ax" output lately? Or used "top"? Or done "git > diff --stat" or any number of things where it turns out that 80x25 is > really really limiting, and is simply NO LONGER RELEVANT to most of > us. > > So no. I do not care about somebody with a 80x25 terminal window > getting line wrapping. > > For exactly the same reason I find it completely irrelevant if > somebody says that their kernel compile takes 10 hours because they > are doing kernel development on a Raspberry PI with 4GB of RAM. > > People with restrictive hardware shouldn't make it more inconvenient > for people who have better resources. Yes, we'll accommodate things to > within reasonable limits. But no, 80-column terminals in 2020 isn't > "reasonable" any more as far as I'm concerned. People commonly used > 132-column terminals even back in the 80's, for chrissake, don't try > to make 80 columns some immovable standard. > > If you choose to use a 80-column terminal, you can live with the line > wrapping. It's just that simple. > > And longer lines are simply useful. Part of that is that we aren't > programming in the 80's any more, and our source code is fundamentally > wider as a result. > > Yes, local iteration variables are still called 'i', because more > context just isn't helpful for some anonymous counter. Being concise > is still a good thing, and overly verbose names are not inherently > better. > > But still - it's entirely reasonable to have variable names that are > 10-15 characters and it makes the code more legible. Writing things > out instead of using abbreviations etc. > > And yes, we do use wide tabs, because that makes indentation something > you can visually see in the structure at a glance and on a > whole-function basis, rather than something you have to try to > visually "line up" things for or count spaces. > > So we have lots of fairly fundamental issues that fairly easily make > for longer lines in many circumstances. > > And yes, we do line breaks at some point. But there really isn't any > reason to make that point be 80 columns any more. > > Linus Regards, Phil.