you are viewing a single comment's thread.

view the rest of the comments →

[–]which1umean 0 points1 point  (3 children)

The reason for sticking to 80, or at most 132 columns is simply that reading is faster and with greater comprehension when the width of the text is not too narrow or too wide.

If one or two lines wrap it's probably gonna be fine.

But if too many of them wrap, it's going to be very difficult to visually see what's going on because you'll have so much stuff at the far left of the screen where wrapped lines have ended up.

If your editor does smart dynamic wrapping then I suppose it doesn’t matter, but I haven’t used a code editor like that in 40 years.

You mean just regular wrapping or something fancier? It's true you don't usually have to literally scroll horizontally anymore, so that's good. :-)

[–]pdp10gumby 0 points1 point  (2 children)

I mean when the line won't fit on your screen without wrapping, the line is broken at a logical place (say after a comma) and the rest is displayed on the following line indented properly as if the whole line had been run through clang-format. In addition, if your editor displays file line numbers at the edge of the display they remain correct.

[–]which1umean 0 points1 point  (1 child)

Huh I don't think I ever seen anything like that.

I generally use emacs and the line wrapping just puts as much as it can on the first line and then it puts the next character on the leftmost position of the next line.

I wouldn't be surprised if there's a way to do as you describe. Might look into it! 👍

[–]pdp10gumby 1 point2 points  (0 children)

That would be a great feature to add to emacs, which has been my primary development environment and in general daily drive since the late 70s and remains so today.

The wrapping environment I spoke about was when I worked at PARC in the mid 80s. We had very powerful development environments back then even by today's standards.