Sure, but there is also a long-standing tradition of making text files readable without soft-wrapping, by using line breaks where it makes sense.
The style guides for many programming languages require you to put hard breaks in long lines, for example. Also, old-school mailing lists require this.
Right, the point I was arguing in my top-level comment is that that tradition is misguided and should be done away with. Including in mailing lists and commit messages.
The place where it "makes sense" to have a line break in prose is a function of the reader's desired line width, which is not only unknown to the author at the time of writing, but also varies from reader to reader. If you don't insert semantically insignificant newline characters, any modern application for reading text can soft-wrap long lines to that width. But because arbitrarily inserting newline characters destroys information, the opposite isn't true. If you add \ns to break your lines at 80 characters and I try to read your text in a 60-character-wide terminal, I'll get alternating line widths of ~60 characters and ~20 characters. And I can't just replace all the newline characters at position ~80 with spaces and re-wrap the resulting text myself, because for all I know one of those line breaks could have been semantically significant.
Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional. If you resize your browser window or zoom in or out so that the line wrapping in this comment occurs at different places in the text, the readability and meaning of this text is essentially unchanged. That's not generally true of code - even in languages whose compilers ignore whitespace, arbitrarily shifting, adding, and deleting line breaks doesn't preserve meaning (to humans) because programmers generally use whitespace methodically for the sake of clarity and readability.
> Line breaks in code are pretty much always semantically significant to the human reader even if they're not semantically significant to the compiler because the relative vertical and horizontal alignment of non-whitespace characters is fixed and intentional.
What would be cool is a well-behaved autoformatter like Black, or perhaps gofmt or rustfmt (clang-format definitely fails since it's not even idempotent), which automatically reflows code to the width of your text editor (or even shrinks the indentation size) as you resize or split the window, and reformats it back to a standard width upon saving and committing. This requires that formatting to a different width then back to the original is a no-op, which I believe Black and rustfmt can achieve, but is harder to get right than storing the code as an AST on-disk. Also, rustfmt fails to reformat the interior of macro invocations.
The style guides for many programming languages require you to put hard breaks in long lines, for example. Also, old-school mailing lists require this.