Comment by helterskelter
1 day ago
My only problem using git and a text editor is deciding whether I want hard or soft wraps. Vim handles hard wraps better IMO and you can change the git diff engine to something like difft, which makes it much more bearable than the default for hard wrap prose.
But softwrap definitely has its advantages: no hard line breaks makes copying the text into other mediums easier, git diffs show only which paragraphs you edited and not a bunch of line diff noise no matter which engine you use. Only problem is it breaks my yy, dd, cc muscle memory, as AFAIK you can't force those to work on virtual (vs logical) lines.
If you use Markdown, then it almost doesn't matter because your converted output won't have a line break until you insert a single newline.
I use VS Code soft-wrapping, and `git diff --word-diff` does all I need, though there probably are better methods.
The annoyances of using "soft wraps" with various kinds of tools is one of the maddening irritations of our software landscape. Inserting non-semantic newlines in content just to make things fit the screen is insane.
It is not just to fit the screen, it also fits our line orientated version control better.
I don't know if this is suitable for large works(books), but for technical documentation I have my plain text source with one line per sentence, actually I go further than than and usually have one line per punctuation. The raw source reads a little hard but the version control diffs are much cleaner and editing is is easier. Most formats(html, troff, tex) ignore manual line returns anyway.
I think most authoring formats require a blank line to mark a paragraph. In emacs and in vim. You can easily reflow such block (and on unix there’s the fmt command).