The common advice[0] is to just write one sentence per line. I usually split at commas etc as well. Then use editor soft wrapping instead of fixing a maximum line length - but if your lines get longer than the screen width that might be a sign your sentences are too complex.

[0]: anyone have a good source for this? I’m not sure where I first encountered it

I will write excessively complex sentences whenever I darn please, and will be hogtied before I stop at the whims of a /diff tool/.

Mock outrage aside, whimsy and play in written language is vastly cheaper than in industrial programming environments. Provided, of course, the author can yet communicate while horsing around.

Did you misunderstand?

One sentence per line doesn't mean your sentence has to be limited in length.

> but if your lines get longer than the screen width that might be a sign your sentences are too complex

It turns out that there is a lot of discourse out there about "semantic newlines", under a few different names. So far the names I've seen are:

- One Sentence Per Line (OSPL) - Semantic Line Breaks (SemBr) - Semantic Linefeeds - Ventilated Prose - Semantic newlines

Reading through the pages below was helpful in getting a better idea of what language people use to discuss this. They're mostly historical retrospectives or arguments for the merit of semantic newlines.

https://rhodesmill.org/brandon/2012/one-sentence-per-line https://ramshankar.org/blog/posts/2019/semantic-line-breaks https://vanemden.wordpress.com/2009/01/01/ventilated-prose https://discuss.python.org/t/semantic-line-breaks/13874 https://discuss.python.org/t/one-sentence-per-line-for-peps-... https://sembr.org https://asciidoctor.org/docs/asciidoc-recommended-practices/...

(Actually I think one-sentence-per-line denotes something slightly different from semantic-line-breaks, not that I know what that difference is).

I am not a slave of the machine. The machine is my tool. The machine will conform to what I want. Not the other way around.

There is no philosophy more important in this age.

In my work I encounter quite a few people beating their heads against walls trying to make the machine "conform to what they want".

You can often achieve your goals much more quickly by using tools they way they best support being used.

And often there is a middleground. In this case one could write a script that outputs a reformatted file with one sentence per line. In Vim this could even be a simple macro as the editor already has a key for jumping to the next sentence.

https://rhodesmill.org/brandon/2012/one-sentence-per-line/ is one possibility. And discusses a Kernighan Unix memo from 1974 advocating for the practice. "UNIX for Beginners" https://web.archive.org/web/20130108163017if_/http://miffy.t... (PDF)

word diff gets you halfway without that complexity

Do you mean the diff system inbuilt into Microsoft Word or Google docs etc?

There is a --word-diff flag in git diff. It can also be customized using --word-diff-regex to possibly match sentences.

I see. From the docs [1]

    --word-diff-regex=<regex> 

      ... A match that contains a newline is silently truncated(!) at the newline.

If I understand this correctly, if you use newlines inside a sentence (if you are writing a fixed width document, for example), this won't work.

[1] https://git-scm.com/docs/git-diff

pipe through "fmt -sw999999999999" first