Guillem Jover <[email protected]> writes: > I think the 80 columns limit still makes sense, as argued for example in > <https://ux.stackexchange.com/questions/3618/ideal-column-width-for-paragraphs-online>.
I also agree with this for code, and I admit that I'm weirdly inconsistent in not caring about it for prose. This is probably a flaw in my own analysis rather than some sort of meaningful subtle distinction. :) > My experience with web tools for code review is that they are also not > great when handling long lines, even with web tools that are otherwise > superior (IMO) in many other axis (such as gerrit), but maybe I've failed > to use some configuration to enable a better experience. Right, the long lines aren't the part that helps (in general, they make it worse). The part that helps is avoiding reflowing the paragraph, which makes it a bit easier for tools to pick out the relevant differences. As you mentioned in the part I trimmed, --word-diff directly addresses the problem, but the other tooling isn't as great around those diffs. > What Simon describes in another mail seems pretty close to «Semantic > Line Breaks» as specified in <https://github.com/sembr/specification>. > And while I find it is not fully visually appealing and bit unnatural, > I also find it functionally appealing and visually not completely > unappealing, so I've been meaning to finish converting for example > the dpkg documentation to some variant of that for a while > <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/man-sembr>. I'd be happy to adopt this as well, for the record, although it might strain my brain a bit since it would be a new, third style. But I adjusted fairly quickly to long lines, so maybe my brain is more flexible than I think it is. Also, it's good for me to make my brain flex! For now, I'm happy to stick with two spaces after periods and flowed paragraphs, but I'm generally open to experimenting with other approaches. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
