linus torvalds — excessive line breaks considered harmful

From the mouth of Torvalds:

On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@aculab.com> 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.

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 “100×50” terminal window (go to your gnome terminal settings, you’ll find that the 80×25 thing is just an initial default that you can change), not with some 80×25 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 142×76 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 80×25 is really really limiting, and is simply NO LONGER RELEVANT to most of us.

So no. I do not care about somebody with a 80×25 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

I haven’t paid attention to the 80 column limit in decades, and got in trouble over it on past programs. If I have a line limit it’s around 120 characters. Any unbroken line that long is an alarm to me to go back and ask why it’s that long, and if necessary, fix it.

As for “wide tabs,” I’m not sure what that’s all about, but in my code I always substitute four spaces/tab, and never use tab characters. Four spaces helps to view code structure at a glance while allow reasonable density in any given body of code. And all of today’s editors and IDEs will provide visual aids to show block scope, so that you can see any given scope in a block. It works with curly brace languages, as well as those that don’t use curly braces (Python primarily).

building emacs 28 on jetpack 4.4 developer preview

By now all of this blog’s readers should realize that when I write about Nvidia’s Jetpack 4.4 Developer Preview (here-after called JP44), I mean the version of Ubuntu 18.04.4 with Nvidia’s software extensions and packages installed.

Earlier I installed all the bits and bobs necessary to build Visual Studio Code on JP44, and managed to get it up and running, mostly. That is, it would open and edit files, it handled syntax highlighting for the sources I cared about, and at least it allowed me to install two extensions. The big problem is that after that first extension installation, the extension list is now empty, meaning I can’t install any others. And I wrote I’d probably stick with it regardless.

Then I remembered I’d extended and configured both Vim and Emacs into very useful tools on my RPi4. I powered up the RPi4 and copied my Vim and Emacs configuration files over to the Jetson Nano and JP44. Easy, right?

For Vim there wasn’t an issue. Everything ran just fine. Emacs installed from the repo was different. I knew I had a problem when the following line in my .emacs file failed on startup with the local emacs:

(global-display-line-numbers-mode)

I checked the version of emacs installed on JP44, and sure enough, it was version 25, one major release back from the version installed on my RPi4 and Raspbian. No, I wasn’t going to change that line (and a few others) back to the older way of doing things. Instead I went over to the Project Emacs page on Savannah ( http://savannah.gnu.org/projects/emacs/ ), followed the directions there to clone from their GitHub repo hosted on Savanah, and went about the business of building an up-to-date emacs.

First time through I was missing a few needed development libraries. I got those installed, got a proper configuration, and then built it. When I fired it up I was horrified to see it was using old school X fonts on everything. Not an anti-aliased font in sight. That just sucked, so I starting looking at the configure output and installing all the necessary libraries emacs needed to support anti aliased fonts. The full list of necessary installs are:

  • texinfo
  • libxaw7-dev
  • libjpeg-dev
  • libpng-dev
  • libgif-dev
  • libtiff-dev
  • gnutls-dev
  • libncurses-dev
  • libfreetype6-dev
  • libcairo-dev

Some of those libraries are needed just to get configure to finish at all. They are listed in the order they were installed. After installing the freetype developer library I got the following interesting warning from configure:

configure: WARNING: This configuration uses libXft, which has a number of
    font rendering issues, and is being considered for removal in the
    next release of Emacs.  Please consider using Cairo graphics +
    HarfBuzz text shaping instead (they are auto-detected if the
    relevant development headers are installed).

Ok. That’s when I installed libcairo-dev. After that it configured and then built. ‘make install’ puts the binary in /usr/local/bin. When I opened up emacs the second time, it was lovely to behold.

Fonts everywhere are nicely rendered and anti-aliased. You’ll note also that this is emacs version 28, which is fine by me. It works with Go, C/C++, Python, and bash, which is all I really need. I also noticed that emac’s memory footprint is tiny compared to VSCode. Which is ironic considering that in the days when men used Vaxen and 1MiB of memory was considered a luxury, emacs was frowned upon by sysadmins who didn’t like how too many emacs sessions could tax those mighty Vaxen. Now I run it on a $100 quad-core 64-bit computer with 4GiB of memory because it’s lean and mean compared to other equivalent tools. My how the times have changed.